OESA-2025-1111

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

i3c: Use i3cdev->desc->info instead of calling i3cdeviceget_info() to avoid deadlock

A deadlock may happen since the i3cmasterregister() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3cdeviceinfo() to avoid acquiring the lock twice.

v2: - Modified the title and commit message

============================================ WARNING: possible recursive locking detected

6.11.0-mainline

init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3cbusnormaluse_lock

but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3cmasterregister

other info that might help us debug this: Possible unsafe locking scenario:

   CPU0
   ----

lock(&i3cbus->lock); lock(&i3cbus->lock);

* DEADLOCK *

May be due to missing lock nesting notation

2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: _driverattach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3cmasterregister

stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dumpbacktrace+0xfc/0x17c showstack+0x18/0x28 dumpstacklvl+0x40/0xc0 dumpstack+0x18/0x24 printdeadlockbug+0x388/0x390 _lockacquire+0x18bc/0x32ec lockacquire+0x134/0x2b0 downread+0x50/0x19c i3cbusnormaluselock+0x14/0x24 i3cdevicegetinfo+0x24/0x58 i3cdeviceuevent+0x34/0xa4 devuevent+0x310/0x384 kobjectueventenv+0x244/0x414 kobjectuevent+0x14/0x20 deviceadd+0x278/0x460 deviceregister+0x20/0x34 i3cmasterregisternewi3cdevs+0x78/0x154 i3cmasterregister+0x6a0/0x6d4 mtki3cmasterprobe+0x3b8/0x4d8 platformprobe+0xa0/0xe0 reallyprobe+0x114/0x454 _driverprobedevice+0xa0/0x15c driverprobedevice+0x3c/0x1ac _driverattach+0xc4/0x1f0 busforeachdev+0x104/0x160 driverattach+0x24/0x34 busadddriver+0x14c/0x294 driverregister+0x68/0x104 _platformdriverregister+0x20/0x30 initmodule+0x20/0xfe4 dooneinitcall+0x184/0x464 doinitmodule+0x58/0x1ec loadmodule+0xefc/0x10c8 _arm64sysfinitmodule+0x238/0x33c invokesyscall+0x58/0x10c el0svccommon+0xa8/0xdc doel0svc+0x1c/0x28 el0svc+0x50/0xac el0t64synchandler+0x70/0xbc el0t64_sync+0x1a8/0x1ac(CVE-2024-43098)

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

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrlselectstate() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.

Let's say two processes A, B executing in pinrequest() for the same pin and process A updates the desc->muxusecount but not yet updated the desc->muxowner while process B see the desc->muxusecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

cpu0 (process A)            cpu1(process B)

pinctrlselectstate() { pinctrlselectstate() { pinrequest() { pinrequest() { ... .... } else { desc->muxusecount++; desc->muxusecount && strcmp(desc->mux_owner, owner)) {

     if (desc->mux_usecount > 1)
           return 0;
     desc->mux_owner = owner;

} }(CVE-2024-47141)

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

net/smc: check smcdv2ext_offset when receiving proposal msg

When receiving proposal msg in server, the field smcdv2extoffset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcdv2extoffset exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the value of smcdv2ext_offset before using it.(CVE-2024-47408)

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

wifi: rtw89: check return value of ieee80211probereqget() for RNR

The return value of ieee80211probereqget() might be NULL, so check it before using to avoid NULL pointer access.

Addresses-Coverity-ID: 1529805 ("Dereference null return value")(CVE-2024-48873)

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

net/smc: check v2extoffset/eidcnt/ismgid_cnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgid_cnt before using them.(CVE-2024-49568)

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

net/smc: check ipareaoffset and ipv6prefixes_cnt when receiving proposal msg

When receiving proposal msg in server, the field ipareaoffset and the field ipv6prefixescnt in proposal msg are from the remote client and can not be fully trusted. Especially the field ipareaoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks ipareaoffset and ipv6prefixes_cnt before using them.(CVE-2024-49571)

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

spi: mpc52xx: Add cancelworksync before module remove

If we remove the module which will call mpc52xxspiremove it will free 'ms' through spiunregistercontroller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug.

Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xxspiremove.(CVE-2024-50051)

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

igb: Fix potential invalid memory access in igbinitmodule()

The pciregisterdriver() can fail and when this happened, the dcanotifier needs to be unregistered, otherwise the dcanotifier can be called when igb fails to install, resulting to invalid memory access.(CVE-2024-52332)

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

drm/mediatek: Fix potential NULL dereference in mtkcrtcdestroy()

In mtkcrtccreate(), if the call to mboxrequestchannel() fails then we set the "mtkcrtc->cmdqclient.chan" pointer to NULL. In that situation, we do not call cmdqpktcreate().

During the cleanup, we need to check if the "mtkcrtc->cmdqclient.chan" is NULL first before calling cmdqpktdestroy(). Calling cmdqpktdestroy() is unnecessary if we didn't call cmdqpktcreate() and it will result in a NULL pointer dereference.(CVE-2024-53056)

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

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function _mmapregion().

Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIGDEBUGVMMAPLETREE validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.

2. The enclosing mmapregion() function handles the mappingmapwritable() logic early. Previously the logic had the mappingmapwritable() at the point of mapping a newly allocated file-backed VMA, and a matching mappingunmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the opposite.

3. We also move archvalidateflags() up into the mmap_region() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason about and more robust.(CVE-2024-53096)

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

mm: pagealloc: move mlocked flag clearance into freepages_prepare()

Syzbot reported a bad page state problem caused by a page being freed using freepage() still having a mlocked flag at freepages_prepare() stage:

BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set pageowner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfpmask 0x400dc0(GFPKERNELACCOUNT|_GFPZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, freets 201499827394 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x1f3/0x230 mm/pagealloc.c:1537 prepnewpage mm/pagealloc.c:1545 [inline] getpagefromfreelist+0x303f/0x3190 mm/pagealloc.c:3457 _allocpagesnoprof+0x292/0x710 mm/pagealloc.c:4733 allocpagesmpolnoprof+0x3e8/0x680 mm/mempolicy.c:2265 kvmcoalescedmmioinit+0x1f/0xf0 virt/kvm/coalescedmmio.c:99 kvmcreatevm virt/kvm/kvmmain.c:1235 [inline] kvmdevioctlcreatevm virt/kvm/kvmmain.c:5488 [inline] kvmdevioctl+0x12dc/0x2240 virt/kvm/kvmmain.c:5530 _docompatsysioctl fs/ioctl.c:1007 [inline] _secompatsysioctl+0x510/0xc90 fs/ioctl.c:950 dosyscall32irqson arch/x86/entry/common.c:165 [inline] _dofastsyscall32+0xb4/0x110 arch/x86/entry/common.c:386 dofastsyscall32+0x34/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: resetpageowner include/linux/pageowner.h:25 [inline] freepagesprepare mm/pagealloc.c:1108 [inline] freeunreffolios+0xf12/0x18d0 mm/pagealloc.c:2686 foliosputrefs+0x76c/0x860 mm/swap.c:1007 freepagesandswapcache+0x5c8/0x690 mm/swapstate.c:335 _tlbbatchfreeencodedpages mm/mmugather.c:136 [inline] tlbbatchpagesflush mm/mmugather.c:149 [inline] tlbflushmmufree mm/mmugather.c:366 [inline] tlbflushmmu+0x3a3/0x680 mm/mmugather.c:373 tlbfinishmmu+0xd4/0x200 mm/mmugather.c:465 exitmmap+0x496/0xc40 mm/mmap.c:1926 _mmput+0x115/0x390 kernel/fork.c:1348 exitmm+0x220/0x310 kernel/exit.c:571 doexit+0x9b2/0x28e0 kernel/exit.c:926 dogroupexit+0x207/0x2c0 kernel/exit.c:1088 _dosysexitgroup kernel/exit.c:1099 [inline] _sesysexitgroup kernel/exit.c:1097 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1097 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 badpage+0x176/0x1d0 mm/pagealloc.c:501 freepageisbad mm/pagealloc.c:918 [inline] freepagesprepare mm/pagealloc.c:1100 [inline] freeunrefpage+0xed0/0xf20 mm/pagealloc.c:2638 kvmdestroyvm virt/kvm/kvmmain.c:1327 [inline] kvmputkvm+0xc75/0x1350 virt/kvm/kvmmain.c:1386 kvmvcpurelease+0x54/0x60 virt/kvm/kvmmain.c:4143 _fput+0x23f/0x880 fs/filetable.c:431 taskworkrun+0x24f/0x310 kernel/taskwork.c:239 exittaskwork include/linux/taskwork.h:43 [inline] doexit+0xa2f/0x28e0 kernel/exit.c:939 dogroupexit+0x207/0x2c0 kernel/exit.c:1088 _dosysexitgroup kernel/exit.c:1099 [in ---truncated---(CVE-2024-53105)

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

Bluetooth: MGMT: Fix slab-use-after-free Read in setpoweredsync

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in setpoweredsync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 Read of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54

CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 q kasanreport+0x143/0x180 mm/kasan/report.c:601 setpoweredsync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 hcicmdsyncwork+0x22b/0x400 net/bluetooth/hcisync.c:328 processonework kernel/workqueue.c:3231 [inline] processscheduledworks+0xa2c/0x1830 kernel/workqueue.c:3312 workerthread+0x86d/0xd10 kernel/workqueue.c:3389 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Allocated by task 5247: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:370 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:387 kasankmalloc include/linux/kasan.h:211 [inline] _kmalloccachenoprof+0x19c/0x2c0 mm/slub.c:4193 kmallocnoprof include/linux/slab.h:681 [inline] kzallocnoprof include/linux/slab.h:807 [inline] mgmtpendingnew+0x65/0x250 net/bluetooth/mgmtutil.c:269 mgmtpendingadd+0x36/0x120 net/bluetooth/mgmtutil.c:296 setpowered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394 hcimgmtcmd+0xc47/0x11d0 net/bluetooth/hcisock.c:1712 hcisocksendmsg+0x7b8/0x11c0 net/bluetooth/hcisock.c:1832 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 sockwriteiter+0x2dd/0x400 net/socket.c:1160 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xa72/0xc90 fs/readwrite.c:590 ksyswrite+0x1a0/0x2c0 fs/readwrite.c:643 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 5246: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject+0xe0/0x150 mm/kasan/common.c:240 _kasanslabfree+0x37/0x60 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2256 [inline] slabfree mm/slub.c:4477 [inline] kfree+0x149/0x360 mm/slub.c:4598 settingsrsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443 mgmtpendingforeach+0xd1/0x130 net/bluetooth/mgmtutil.c:259 _mgmtpoweroff+0x112/0x420 net/bluetooth/mgmt.c:9455 hcidevclosesync+0x665/0x11a0 net/bluetooth/hcisync.c:5191 hcidevdoclose net/bluetooth/hcicore.c:483 [inline] hcidevclose+0x112/0x210 net/bluetooth/hcicore.c:508 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83gv entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-53208)

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

zram: fix NULL pointer in compalgorithmshow()

LTP reported a NULL pointer dereference as followed:

CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _pistrcmp+0x24/0x140 lr : zcompavailableshow+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Call trace: _pistrcmp+0x24/0x140 compalgorithmshow+0x40/0x70 [zram] devattrshow+0x28/0x80 sysfskfseqshow+0x90/0x140 kernfsseqshow+0x34/0x48 seqreaditer+0x1d4/0x4e8 kernfsfopreaditer+0x40/0x58 newsyncread+0x9c/0x168 vfsread+0x1a8/0x1f8 ksysread+0x74/0x108 _arm64sysread+0x24/0x38 invokesyscall+0x50/0x120 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x38/0x138 el0t64synchandler+0xc0/0xc8 el0t64sync+0x188/0x190

The zram->compalgs[ZRAMPRIMARYCOMP] can be NULL in zramadd() if compalgorithmset() has not been called. User can access the zram device by sysfs after deviceadddisk(), so there is a time window to trigger the NULL pointer dereference. Move it ahead deviceadddisk() to make sure when user can access the zram device, it is ready. compalgorithmset() is protected by zram->init_lock in other places and no such problem.(CVE-2024-53222)

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

nilfs2: prevent use of deleted inode

syzbot reported a WARNING in nilfs_rmdir. [1]

Because the inode bitmap is corrupted, an inode with an inode number that should exist as a ".nilfs" file was reassigned by nilfsmkdir for "file0", causing an inode duplication during execution. And this causes an underflow of inlink in rmdir operations.

The inode is used twice by the same task to unmount and remove directories ".nilfs" and "file0", it trigger warning in nilfs_rmdir.

Avoid to this issue, check inlink in nilfsiget(), if it is 0, it means that this inode has been deleted, and iput is executed to reclaim it.

[1] WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 dropnlink+0xc4/0x110 fs/inode.c:407 ... Call Trace: <TASK> nilfsrmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 vfsrmdir+0x3a3/0x510 fs/namei.c:4394 dormdir+0x3b5/0x580 fs/namei.c:4453 _dosysrmdir fs/namei.c:4472 [inline] _sesysrmdir fs/namei.c:4470 [inline] _x64sysrmdir+0x47/0x50 fs/namei.c:4470 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-53690)

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

drm/modes: Avoid divide by zero harder in drmmodevrefresh()

drmmodevrefresh() is trying to avoid divide by zero by checking whether htotal or vtotal are zero. But we may still end up with a div-by-zero of vtotalhtotal...(CVE-2024-56369)

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

kcsan: Turn reportfilterlistlock into a raw_spinlock

Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see splats like:

| BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 | inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 0, name: swapper/1 | preemptcount: 10002, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 156674 | hardirqs last enabled at (156673): [<ffffffff81130bd9>] doidle+0x1f9/0x240 | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvecapictimerinterrupt+0x14/0xc0 | softirqs last enabled at (0): [<ffffffff81099f47>] copyprocess+0xfc7/0x4b60 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | Preemption disabled at: | [<ffffffff814a3e2a>] paintptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Call Trace: | <IRQ> | dumpstacklvl+0x7e/0xc0 | dumpstack+0x1d/0x30 | _mightresched+0x1a2/0x270 | rtspinlock+0x68/0x170 | kcsanskipreportdebugfs+0x43/0xe0 | printreport+0xb5/0x590 | kcsanreportknownorigin+0x1b1/0x1d0 | kcsansetupwatchpoint+0x348/0x650 | _tsanunalignedwrite1+0x16d/0x1d0 | hrtimerinterrupt+0x3d6/0x430 | _sysvecapictimerinterrupt+0xe8/0x3a0 | sysvecapictimerinterrupt+0x97/0xc0 | </IRQ>

On a detected data race, KCSAN's reporting logic checks if it should filter the report. That list is protected by the reportfilterlistlock non-raw spinlock which may sleep on RT kernels.

Since KCSAN may report data races in any context, convert it to a raw_spinlock.

This requires being careful about when to allocate memory for the filter list itself which can be done via KCSAN's debugfs interface. Concurrent modification of the filter list via debugfs should be rare: the chosen strategy is to optimistically pre-allocate memory before the critical section and discard if unused.(CVE-2024-56610)

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

cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU

Commit

5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")

adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit

6539cffa9495 ("cacheinfo: Add arch specific early level initializer")

lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed.

If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, lastlevelcacheisvalid() attempts to dereference a NULL pointer:

BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: lastlevelcacheis_valid+0x95/0xe0a

Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier.

Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cacheleaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cacheleaves() before allocation.

Dereferencing NULL cacheinfo can occur in updatepercpudataslice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet.

While here, remove an unnecessary indentation in allocatecacheinfo().

bp: Massage.

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

usb: dwc3: gadget: Fix looping of queued SG entries

The dwc3request->numqueuedsgs is decremented on completion. If a partially completed request is handled, then the dwc3request->numqueuedsgs no longer reflects the total number of numqueuedsgs (it would be cleared).

Correctly check the number of request SG entries remained to be prepare and queued. Failure to do this may cause null pointer dereference when accessing non-existent SG entry.(CVE-2024-56698)

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

ionic: Fix netdev notifier unregister on failure

If registernetdev() fails, then the driver leaks the netdev notifier. Fix this by calling ioniclifunregister() on registernetdev() failure. This will also call ioniclifunregister_phc() if it has already been registered.(CVE-2024-56715)

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

net/smc: check return value of sock_recvmsg when draining clc data

When receiving clc msg, the field length in smcclcmsghdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smcclcwaitmsg it may run into deadloop when trying to drain the remaining data exceeding buflen.

This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining.(CVE-2024-57791)

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

net: fix memory leak in tcpconnrequest()

If inetcskreqskqueuehashadd() return false, tcpconnrequest() will return without free the dst memory, which allocated in afops->route_req.

Here is the kmemleak stack:

unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmemcachealloc+0x60c/0xa80 [<ffffffffba11b4c5>] dstalloc+0x55/0x250 [<ffffffffba227bf6>] rtdstalloc+0x46/0x1d0 [<ffffffffba23050a>] _mkrouteoutput+0x29a/0xa50 [<ffffffffba23456b>] iprouteoutputkeyhash+0x10b/0x240 [<ffffffffba2346bd>] iprouteoutputflow+0x1d/0x90 [<ffffffffba254855>] inetcskroutereq+0x2c5/0x500 [<ffffffffba26b331>] tcpconnrequest+0x691/0x12c0 [<ffffffffba27bd08>] tcprcvstateprocess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcpv4dorcv+0x156/0x3b0 [<ffffffffba299c98>] tcpv4rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ipprotocoldeliverrcu+0xf6/0x360 [<ffffffffba2399a6>] iplocaldeliverfinish+0xe6/0x1e0 [<ffffffffba239b8e>] iplocaldeliver+0xee/0x360 [<ffffffffba239ead>] iprcv+0xad/0x2f0 [<ffffffffba110943>] _netifreceiveskbone_core+0x123/0x140

Call dstrelease() to free the dst memory when inetcskreqskqueuehashadd() return false in tcpconnrequest().(CVE-2024-57841)

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

mptcp: fix TCP options overflow.

Syzbot reported the following splat:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:compoundhead include/linux/page-flags.h:242 [inline] RIP: 0010:putpage+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpageunref include/linux/skbuffref.h:43 [inline] _skbfragunref include/linux/skbuffref.h:56 [inline] skbreleasedata+0x483/0x8a0 net/core/skbuff.c:1119 skbreleaseall net/core/skbuff.c:1190 [inline] _kfreeskb+0x55/0x70 net/core/skbuff.c:1204 tcpcleanrtxqueue net/ipv4/tcpinput.c:3436 [inline] tcpack+0x2442/0x6bc0 net/ipv4/tcpinput.c:4032 tcprcvstateprocess+0x8eb/0x44e0 net/ipv4/tcpinput.c:6805 tcpv4dorcv+0x77d/0xc70 net/ipv4/tcpipv4.c:1939 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 _netifreceiveskbonecore net/core/dev.c:5672 [inline] _netifreceiveskb+0x2bf/0x650 net/core/dev.c:5785 processbacklog+0x662/0x15b0 net/core/dev.c:6117 _napipoll+0xcb/0x490 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:7074 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 _dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] _irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asmsysvecapictimer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK>

Eric noted a probable shinfo->nr_frags corruption, which indeed occurs.

The root cause is a buggy MPTCP option len computation in some circumstances: the ADD_ADDR option should be mutually exclusive with DSS since the blamed commit.

Still, mptcpestablishedoptionsaddaddr() tries to set the relevant info in mptcpoutoptions, if ---truncated---(CVE-2024-57882)

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

workqueue: Do not warn when cancelling WQMEMRECLAIM work from !WQMEMRECLAIM worker

After commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQMEMRECLAIM") amdgpu started seeing the following warning:

[ ] workqueue: WQMEMRECLAIM sdma0:drmschedrunjobwork [gpusched] is flushing !WQMEMRECLAIM events:amdgpudevicedelayenablegfxoff [amdgpu] ... [ ] Workqueue: sdma0 drmschedrunjobwork [gpusched] ... [ ] Call Trace: [ ] <TASK> ... [ ] ? checkflushdependency+0xf5/0x110 ... [ ] canceldelayedworksync+0x6e/0x80 [ ] amdgpugfxoffctrl+0xab/0x140 [amdgpu] [ ] amdgpuringalloc+0x40/0x50 [amdgpu] [ ] amdgpuibschedule+0xf4/0x810 [amdgpu] [ ] ? drmschedrunjobwork+0x22c/0x430 [gpusched] [ ] amdgpujobrun+0xaa/0x1f0 [amdgpu] [ ] drmschedrunjobwork+0x257/0x430 [gpusched] [ ] processone_work+0x217/0x720 ... [ ] </TASK>

The intent of the verifcation done in checkflushdepedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe.

This is correct when flushing, but when called from the cancel(delayed)work_sync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context.

References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQMEMRECLAIM")(CVE-2024-57888)

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

misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling

Resolve kernel panic caused by improper handling of IRQs while accessing GPIO values. This is done by replacing generichandleirq with handlenestedirq.(CVE-2024-57916)

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

ksmbd: fix a missing return value check bug

In the smb2sendinterimresp(), if ksmbdallocworkstruct() fails to allocate a node, it returns a NULL pointer to the inwork pointer. This can lead to an illegal memory write of inwork->responsebuf when allocateinterimrspbuf() attempts to perform a kzalloc() on it.

To address this issue, incorporating a check for the return value of ksmbdallocwork_struct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access.(CVE-2024-57925)

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

gve: guard XDP xmit NDO on existence of xdp queues

In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false.

In the case of no loaded XDP program, priv->numxdpqueues=0 which can cause a divide-by-zero error, and in the case of interface down, numxdpqueues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL.

The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVEPRIVFLAGSNAPIENABLED bit along with a synchronize_net() call, which waits for any RCU critical sections at call-time to complete.(CVE-2024-57932)

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

gve: guard XSK operations on the existence of queues

This patch predicates the enabling and disabling of XSK pools on the existence of queues. As it stands, if the interface is down, disabling or enabling XSK pools would result in a crash, as the RX queue pointer would be NULL. XSK pool registration will occur as part of the next interface up.

Similarly, xskwakeup needs be guarded against queues disappearing while the function is executing, so a check against the GVEPRIVFLAGSNAPIENABLED flag is added to synchronize with the disabling of the bit and the synchronizenet() in gve_turndown.(CVE-2024-57933)

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

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c _mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea _newvmallocrestorecontext_a0+0xcc/0xd8 Oops - illegal instruction [#1]

Switch to use rawspinlockt, which does not sleep even with PREEMPT_RT enabled.(CVE-2024-57939)

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

exfat: fix the infinite loop in exfat_readdir()

If the file system is corrupted so that a cluster is linked to itself in the cluster chain, and there is an unused directory entry in the cluster, 'dentry' will not be incremented, causing condition 'dentry < max_dentries' unable to prevent an infinite loop.

This infinite loop causes slock not to be released, and other tasks will hang, such as exfatsync_fs().

This commit stops traversing the cluster chain when there is unused directory entry in the cluster to avoid this infinite loop.(CVE-2024-57940)

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

netfilter: nfsetpipapo: fix initial map fill

The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size.

After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map.

This makes pipapo find an incorrect matching results for sets where first field size is not the largest.

Followup patch adds a test case to nftconcatrange.sh selftest script.

Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough.(CVE-2024-57947)

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

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wake_depth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirq_wake+0x147/0x1a0

The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pm_suspend(), however, is only set as the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.

ij: edited the commit message.

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

gpio: xilinx: Convert gpio_lock to raw spinlock

irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking.

This fixes the following lockdep splat:

[ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpiolock){....}-{3:3}, at: xgpioirqunmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: processonework (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferredprobework){+.+.}-{0:0}, at: processonework (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: _deviceattach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (requestclass#2){+.+.}-{4:4}, at: _setupirq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lockclass#2){....}-{2:2}, at: _setupirq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: eventsunbound deferredprobeworkfunc [ 5.461699] Call trace: [ 5.464147] showstack+0x18/0x24 C [ 5.467821] dumpstacklvl (lib/dumpstack.c:123) [ 5.471501] dumpstack (lib/dumpstack.c:130) [ 5.474824] _lockacquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lockacquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] rawspinlockirqsave (include/linux/spinlockapismp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpioirqunmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irqenable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] _irqstartup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irqstartup (kernel/irq/chip.c:270) [ 5.501143] _setupirq (kernel/irq/manage.c:1807) [ 5.504728] requestthreadedirq (kernel/irq/manage.c:2208)(CVE-2025-21684)