The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

nfc: fix segfault in nfcgenldumpdevicesdone

When kmalloc in nfcgenldumpdevices() fails then nfcgenldumpdevices_done() segfaults as below

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014 Workqueue: events netlinksockdestructwork RIP: 0010:klistiterexit+0x26/0x80 Call Trace: <TASK> classdeviterexit+0x15/0x20 nfcgenldumpdevicesdone+0x3b/0x50 genllockdone+0x84/0xd0 netlinksockdestruct+0x8f/0x270 _skdestruct+0x64/0x3b0 skdestruct+0xa8/0xd0 _skfree+0x2e8/0x3d0 skfree+0x51/0x90 netlinksockdestructwork+0x1c/0x20 processonework+0x411/0x710 workerthread+0x6fd/0xa80(CVE-2021-47612)

In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Fix memory leak in vmbusaddchannel_kobj

kobjectinitandadd() takes reference even when it fails. According to the doc of kobjectinitandadd()?

If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.

Fix memory leak by calling kobject_put().(CVE-2022-48775)

In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: fix possible use-after-free in transport error_recovery work

While nvmerdmasubmitasynceventwork is checking the ctrl and queue state before preparing the AER command and scheduling iowork, in order to fully prevent a race where this check is not reliable the error recovery work must flush asynceventwork before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submitasyncevent and the error recovery handler itself changing the ctrl state.(CVE-2022-48788)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: Fix use-after-free bug by not setting udc->dev.driver

The syzbot fuzzer found a use-after-free bug:

BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689

CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printaddressdescription.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 _kasanreport mm/kasan/report.c:442 [inline] kasanreport.cold+0x83/0xdf mm/kasan/report.c:459 devuevent+0x712/0x780 drivers/base/core.c:2320 ueventshow+0x1b8/0x380 drivers/base/core.c:2391 devattr_show+0x4b/0x90 drivers/base/core.c:2094

Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does:

if (dev->driver)
    add_uevent_var(env, "DRIVER=%s", dev->driver->name);

and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL.

The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL.

In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC.

This patch simply removes the statements in the gadget core that touch udc->dev.driver.(CVE-2022-48838)

In the Linux kernel, the following vulnerability has been resolved:

sctp: fix kernel-infoleak for SCTP sockets

syzbot reported a kernel infoleak [1] of 4 bytes.

After analysis, it turned out r->idiagexpires is not initialized if inetsctpdiagfill() calls inetdiagmsgcommonfill()

Make sure to clear idiagtimer/idiagretrans/idiagexpires and let inetdiagmsgsctpasoc_fill() fill them again if needed.

[1]

BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/ioviter.c:154 [inline] BUG: KMSAN: kernel-infoleak in copytoiter+0x6ef/0x25a0 lib/ioviter.c:668 instrumentcopytouser include/linux/instrumented.h:121 [inline] copyout lib/ioviter.c:154 [inline] copytoiter+0x6ef/0x25a0 lib/ioviter.c:668 copytoiter include/linux/uio.h:162 [inline] simplecopytoiter+0xf3/0x140 net/core/datagram.c:519 _skbdatagramiter+0x2d5/0x11b0 net/core/datagram.c:425 skbcopydatagramiter+0xdc/0x270 net/core/datagram.c:533 skbcopydatagrammsg include/linux/skbuff.h:3696 [inline] netlinkrecvmsg+0x669/0x1c80 net/netlink/afnetlink.c:1977 sockrecvmsgnosec net/socket.c:948 [inline] sockrecvmsg net/socket.c:966 [inline] _sysrecvfrom+0x795/0xa10 net/socket.c:2097 _dosysrecvfrom net/socket.c:2115 [inline] _sesysrecvfrom net/socket.c:2111 [inline] _x64sysrecvfrom+0x19d/0x210 net/socket.c:2111 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x54/0xd0 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x44/0xae

Uninit was created at: slabpostallochook mm/slab.h:737 [inline] slaballocnode mm/slub.c:3247 [inline] _kmallocnodetrackcaller+0xe0c/0x1510 mm/slub.c:4975 kmallocreserve net/core/skbuff.c:354 [inline] _allocskb+0x545/0xf90 net/core/skbuff.c:426 allocskb include/linux/skbuff.h:1158 [inline] netlinkdump+0x3e5/0x16c0 net/netlink/afnetlink.c:2248 _netlinkdumpstart+0xcf8/0xe90 net/netlink/afnetlink.c:2373 netlinkdumpstart include/linux/netlink.h:254 [inline] inetdiaghandlercmd+0x2e7/0x400 net/ipv4/inetdiag.c:1341 sockdiagrcvmsg+0x24a/0x620 netlinkrcvskb+0x40c/0x7e0 net/netlink/afnetlink.c:2494 sockdiagrcv+0x63/0x80 net/core/sockdiag.c:277 netlinkunicastkernel net/netlink/afnetlink.c:1317 [inline] netlinkunicast+0x1093/0x1360 net/netlink/afnetlink.c:1343 netlinksendmsg+0x14d9/0x1720 net/netlink/afnetlink.c:1919 socksendmsgnosec net/socket.c:705 [inline] socksendmsg net/socket.c:725 [inline] sockwriteiter+0x594/0x690 net/socket.c:1061 doiterreadvwritev+0xa7f/0xc70 doiterwrite+0x52c/0x1500 fs/readwrite.c:851 vfswritev fs/readwrite.c:924 [inline] dowritev+0x645/0xe00 fs/readwrite.c:967 _dosyswritev fs/readwrite.c:1040 [inline] _sesyswritev fs/readwrite.c:1037 [inline] _x64syswritev+0xe5/0x120 fs/readwrite.c:1037 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x54/0xd0 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x44/0xae

Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0

CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-48855)

In the Linux kernel, the following vulnerability has been resolved:

gianfar: ethtool: Fix refcount leak in gfargetts_info

The offindcompatiblenode() function returns a node pointer with refcount incremented, We should use ofnodeput() on it when done Add the missing ofnode_put() to release the refcount.(CVE-2022-48856)

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix kernel panic when enabling bearer

When enabling a bearer on a node, a kernel panic is observed:

[ 4.498085] RIP: 0010:tipcmonprep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipclinkbuildprotomsg+0x375/0x750 [tipc] [ 4.522654] tipclinkbuildstatemsg+0x48/0xc0 [tipc] [ 4.524034] _tipcnodelinkup+0xd7/0x290 [tipc] [ 4.525292] tipcrcv+0x5da/0x730 [tipc] [ 4.526346] ? _netifreceiveskbcore+0xb7/0xfc0 [ 4.527601] tipcl2rcvmsg+0x5e/0x90 [tipc] [ 4.528737] _netifreceiveskblistcore+0x20b/0x260 [ 4.530068] netifreceiveskblistinternal+0x1bf/0x2e0 [ 4.531450] ? devgroreceive+0x4c2/0x680 [ 4.532512] napicompletedone+0x6f/0x180 [ 4.533570] virtnetpoll+0x29c/0x42e [virtio_net] ...

The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread:

     thread 1           |              thread 2
     --------           |              --------
                        |

tipcenablebearer() | testandsetbitlock() | tipcbearerxmitskb() | | tipcl2rcvmsg() | tipcrcv() | _tipcnodelinkup() | tipclinkbuildstatemsg() | tipclinkbuildprotomsg() | tipcmonprep() | { | ... | // null-pointer dereference | u16 gen = mon->domgen; | ... | } // Not being executed yet | tipcmoncreate() | { | ... | // allocate | mon = kzalloc(); | ... | } |

Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. This causes kernel panic.

This commit fixes it by allocating the monitoring data before enabling the bearer to receive messages.(CVE-2022-48865)

In the Linux kernel, the following vulnerability has been resolved:

netrom: fix possible dead-lock in nrrtioctl()

syzbot loves netrom, and found a possible deadlock in nrrtioctl [1]

Make sure we always acquire nrnodelistlock before nrnodelock(nrnode)

[1] WARNING: possible circular locking dependency detected

6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted

syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrnodelock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrdecobs net/netrom/nrroute.c:464 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrrtioctl+0x1bb/0x1090 net/netrom/nrroute.c:697

but task is already holding lock: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrdecobs net/netrom/nrroute.c:462 [inline] ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrrtioctl+0x10a/0x1090 net/netrom/nr_route.c:697

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (nrnodelistlock){+...}-{2:2}: lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 _rawspinlockbh include/linux/spinlockapismp.h:126 [inline] rawspinlockbh+0x35/0x50 kernel/locking/spinlock.c:178 spinlockbh include/linux/spinlock.h:356 [inline] nrremovenode net/netrom/nrroute.c:299 [inline] nrdelnode+0x4b4/0x820 net/netrom/nrroute.c:355 nrrtioctl+0xa95/0x1090 net/netrom/nrroute.c:683 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

-> #0 (&nrnode->nodelock){+...}-{2:2}: checkprevadd kernel/locking/lockdep.c:3134 [inline] checkprevsadd kernel/locking/lockdep.c:3253 [inline] validatechain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 _lockacquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 _rawspinlockbh include/linux/spinlockapismp.h:126 [inline] rawspinlockbh+0x35/0x50 kernel/locking/spinlock.c:178 spinlockbh include/linux/spinlock.h:356 [inline] nrnodelock include/net/netrom.h:152 [inline] nrdecobs net/netrom/nrroute.c:464 [inline] nrrtioctl+0x1bb/0x1090 net/netrom/nrroute.c:697 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(nrnodelistlock); lock(&nrnode->nodelock); lock(nrnodelistlock); lock(&nrnode->nodelock);

* DEADLOCK *

1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrdecobs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---(CVE-2024-38589)

In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - Fix ADFDEVRESET_SYNC memory leak

Using completiondone to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called waitfor_completion, resulting in another potential UAF.

Fix this by making the caller use cancelworksync and then freeing the memory safely.(CVE-2024-39493)

In the Linux kernel, the following vulnerability has been resolved:

ima: Fix use-after-free on a dentry's dname.name

->dname.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->dlock on dentry, ->dlock on its parent, ->irwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.(CVE-2024-39494)

In the Linux kernel, the following vulnerability has been resolved:

vmci: prevent speculation leaks by sanitizing event in event_deliver()

Coverity spotted that eventmsg is controlled by user-space, eventmsg->eventdata.event is passed to eventdeliver() and used as an index without sanitization.

This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Only compile tested, no access to HW.(CVE-2024-39499)

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:

wifi: mac80211: Fix deadlock in ieee80211stapsdeliverwakeup()

The ieee80211stapsdeliverwakeup() function takes sta->pslock to synchronizes with ieee80211txhunicastpsbuf() which is called from softirq context. However using only spinlock() to get sta->pslock in ieee80211stapsdeliverwakeup() does not prevent softirq to execute on this same CPU, to run ieee80211txhunicastps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.

rcu: INFO: rcusched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpasupplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queuedspinlockslowpath+0x58/0x2d0 lr : invoketxhandlersearly+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queuedspinlockslowpath+0x58/0x2d0 ieee80211tx+0x80/0x12c ieee80211txpending+0x110/0x278 taskletactioncommon.constprop.0+0x10c/0x144 taskletaction+0x20/0x28 _stext+0x11c/0x284 dosoftirq+0xc/0x14 callonirqstack+0x24/0x34 dosoftirqownstack+0x18/0x20 dosoftirq+0x74/0x7c _localbhenableip+0xa0/0xa4 _ieee80211waketxqs+0x3b0/0x4b8 _ieee80211wakequeue+0x12c/0x168 ieee80211addpendingskbs+0xec/0x138 ieee80211stapsdeliverwakeup+0x2a4/0x480 ieee80211mpsstastatusupdate.part.0+0xd8/0x11c ieee80211mpsstastatusupdate+0x18/0x24 staapplyparameters+0x3bc/0x4c0 ieee80211changestation+0x1b8/0x2dc nl80211setstation+0x444/0x49c genlfamilyrcvmsgdoit.isra.0+0xa4/0xfc genlrcvmsg+0x1b0/0x244 netlinkrcvskb+0x38/0x10c genlrcv+0x34/0x48 netlinkunicast+0x254/0x2bc netlinksendmsg+0x190/0x3b4 syssendmsg+0x1e8/0x218 _syssendmsg+0x68/0x8c _syssendmsg+0x44/0x84 _arm64syssendmsg+0x20/0x28 doel0svc+0x6c/0xe8 el0svc+0x14/0x48 el0t64synchandler+0xb0/0xb4 el0t64_sync+0x14c/0x150

Using spinlockbh()/spinunlockbh() instead prevents softirq to raise on the same CPU that is holding the lock.(CVE-2024-40912)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: check n_ssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even though nssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking nssids first.(CVE-2024-40929)

In the Linux kernel, the following vulnerability has been resolved:

drm/exynos/vidi: fix memory leak in .get_modes()

The duplicated EDID is never freed. Fix it.(CVE-2024-40932)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing.

This was reported by KFENCE.(CVE-2024-40941)

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix races between hole punching and AIO+DIO

After commit "ocfs2: return real error code in ocfs2diowrgetblock", fstests/generic/300 become from always failed to sometimes failed:

======================================================================== [ 473.293420 ] run fstests generic/300

[ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2changeextentflag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2markextentwritten:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2dioendiowrite:2374 ERROR: status = -3

fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072

In _blockdevdirectIO, ocfs2diowrgetblock is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2writebeginnolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2removeextent(). At end io worker thread, ocfs2searchextent_list found there is no such extent at the cpos.

T1                        T2                T3
                          inode lock
                            ...
                            insert extents
                            ...
                          inode unlock

ocfs2fallocate _ocfs2changefilespace inode lock lock ipallocsem ocfs2removeinoderange inode ocfs2removebtreerange ocfs2removeextent ^---remove the extent at cpos 78723 ... unlock ipallocsem inode unlock ocfs2dioendio ocfs2dioendiowrite lock ipallocsem ocfs2markextentwritten ocfs2changeextentflag ocfs2searchextentlist ^---failed to find extent ... unlock ipalloc_sem

In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.(CVE-2024-40943)

In the Linux kernel, the following vulnerability has been resolved:

MIPS: Octeon: Add PCIe link status check

The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic.(CVE-2024-40968)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: Enforce hcall result buffer validity and size

plparhcall(), plparhcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea.

For example, if I write a bug like this:

long retbuf[PLPARHCALLBUFSIZE]; // should be PLPARHCALL9BUFSIZE plparhcall9(HALLOCATEVASWINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this:

error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plparhcall9(HALLOCATEVASWINDOW, retbuf, | ^ ~~~~~~

[1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.(CVE-2024-40974)

In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present.

However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference.

Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.(CVE-2024-40984)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumovidmapping_entry.(CVE-2024-40987)

In the Linux kernel, the following vulnerability has been resolved:

netpoll: Fix race condition in netpollowneractive

KCSAN detected a race condition in netpoll:

BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)

<snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpollsendskb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpollsendudp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff

This happens because netpollowneractive() needs to check if the current CPU is the owner of the lock, touching napi->pollowner non atomically. The ->pollowner field contains the current CPU holding the lock.

Use an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)

In the Linux kernel, the following vulnerability has been resolved:

tcp: avoid too many retransmit packets

If a TCP socket is using TCPUSERTIMEOUT, and the other peer retracted its window to zero, tcpretransmittimer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCPUSERTIMEOUT has 'expired'.

The fix is to make sure tcprtxprobe0timedout() takes icsk->icskusertimeout into account.

Before blamed commit, the socket would not timeout after icsk->icskusertimeout, but would use standard exponential backoff for the retransmits.

Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.(CVE-2024-41007)