The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: seville: register the mdiobus under devres
As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slavemiibus using devres")
mdiobusfree() will panic when called from devmmdiobusfree() <- devresreleaseall() <- _devicereleasedriver(), and that mdiobus was not previously unregistered.
The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here.
If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and devicelinksunbind_consumers() will unbind the seville switch driver on shutdown.
So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all.
The seville driver has a code structure that could accommodate both the mdiobusunregister and mdiobusfree calls, but it has an external dependency upon msccmiimsetup() from mdio-mscc-miim.c, which calls devmmdiobusallocsize() on its behalf. So rather than restructuring that, and exporting yet one more symbol msccmiimteardown(), let's work with devres and replace ofmdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none).(CVE-2022-48814)
In the Linux kernel, the following vulnerability has been resolved:
nfs: Handle error of rpcprocregister() in nfsnetinit().
syzkaller reported a warning [0] triggered while destroying immature netns.
rpcprocregister() was called in initnfsfs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2").
Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible.
Even when rpcprocregister() fails, nfsnetinit() could succeed, and thus nfsnetexit() will be called while destroying the netns.
Then, removeprocentry() will be called for non-existing proc directory and trigger the warning below.
Let's handle the error of rpcprocregister() properly in nfsnetinit().
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpcprocunregister+0x64/0x70 net/sunrpc/stats.c:310 nfsnetexit+0x1c/0x30 fs/nfs/inode.c:2438 opsexitlist+0x62/0xb0 net/core/netnamespace.c:170 setupnet+0x46c/0x660 net/core/netnamespace.c:372 copynetns+0x244/0x590 net/core/netnamespace.c:505 createnewnamespaces+0x2ed/0x770 kernel/nsproxy.c:110 unsharensproxynamespaces+0xae/0x160 kernel/nsproxy.c:228 ksysunshare+0x342/0x760 kernel/fork.c:3322 _dosysunshare kernel/fork.c:3393 [inline] _sesysunshare kernel/fork.c:3391 [inline] _x64sysunshare+0x1f/0x30 kernel/fork.c:3391 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4f/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>(CVE-2024-36939)
In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup:
cdcwdm 1-1:1.0: nonzero urb status received: -71 cdcwdm 1-1:1.0: wdmintcallback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] consoleemitnextrecord kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] consoleflushall+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] _el1irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirqhandleend kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handlesoftirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] _do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two deverr() calls. Therefore we replace them with deverr_ratelimited().(CVE-2024-40904)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible race in _fib6droppcpufrom()
syzbot found a race in _fib6droppcpufrom() [1]
If compiler reads more than once (*ppcpurt), second read could read NULL, if another cpu clears the value in rt6getpcpuroute().
Add a READ_ONCE() to prevent this race.
Also add rcureadlock()/rcureadunlock() because we rely on RCU protection while dereferencing pcpu_rt.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanupnet RIP: 0010:fib6droppcpufrom.part.0+0x10a/0x370 net/ipv6/ip6fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _fib6droppcpufrom net/ipv6/ip6fib.c:966 [inline] fib6droppcpufrom net/ipv6/ip6fib.c:1027 [inline] fib6purgert+0x7f2/0x9f0 net/ipv6/ip6fib.c:1038 fib6delroute net/ipv6/ip6fib.c:1998 [inline] fib6del+0xa70/0x17b0 net/ipv6/ip6fib.c:2043 fib6cleannode+0x426/0x5b0 net/ipv6/ip6fib.c:2205 fib6walkcontinue+0x44f/0x8d0 net/ipv6/ip6fib.c:2127 fib6walk+0x182/0x370 net/ipv6/ip6fib.c:2175 fib6cleantree+0xd7/0x120 net/ipv6/ip6fib.c:2255 _fib6cleanall+0x100/0x2d0 net/ipv6/ip6fib.c:2271 rt6syncdowndev net/ipv6/route.c:4906 [inline] rt6disableip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconfifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconfnotify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifiercallchain+0xb9/0x410 kernel/notifier.c:93 callnetdevicenotifiersinfo+0xbe/0x140 net/core/dev.c:1992 callnetdevicenotifiersextack net/core/dev.c:2030 [inline] callnetdevicenotifiers net/core/dev.c:2044 [inline] devclosemany+0x333/0x6a0 net/core/dev.c:1585 unregisternetdevicemanynotify+0x46d/0x19f0 net/core/dev.c:11193 unregisternetdevicemany net/core/dev.c:11276 [inline] defaultdeviceexitbatch+0x85b/0xae0 net/core/dev.c:11759 opsexitlist+0x128/0x180 net/core/netnamespace.c:178 cleanupnet+0x5b7/0xbf0 net/core/netnamespace.c:640 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244(CVE-2024-40905)
{ "severity": "Medium" }
{ "x86_64": [ "bpftool-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-headers-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-source-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-tools-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "python3-perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm", "python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm" ], "src": [ "kernel-5.10.0-220.0.0.119.oe2203sp4.src.rpm" ], "aarch64": [ "bpftool-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-headers-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-source-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-tools-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "python3-perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm", "python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm" ] }