OESA-2024-2369

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdiodevicerelease() There is warning report about ofnode refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, ofnodeget()/ofnodeput() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In ofmdiobusregisterdevice(), we increase fwnode refcount by fwnodehandleget() before associating the ofnode with mdio device, but it has never been decreased in normal path. Since that, in mdiodevicerelease(), it needs to call fwnodehandleput() in addition instead of calling kfree() directly. After above, just calling mdiodevicefree() in the error handle path of ofmdiobusregisterdevice() is enough to keep the refcount balanced.(CVE-2022-48961)

In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochipsetupdev() Here is a backtrace report about memory leak detected in gpiochipsetupdev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloctrace deviceadd deviceprivateinit at drivers/base/core.c:3361 (inlined by) deviceadd at drivers/base/core.c:3411 cdevdeviceadd gpiolibcdevregister gpiochipsetupdev gpiochipadddatawithkey gcdevregister() & gcdevunregister() would call deviceadd() & devicedel() (no matter CONFIGGPIOCDEV is enabled or not) to register/unregister device. However, if deviceadd() succeeds, some resource (like struct deviceprivate allocated by deviceprivateinit()) is not released by devicedel(). Therefore, after deviceadd() succeeds by gcdevregister(), it needs to call putdevice() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by putdevice() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.(CVE-2022-48975)

In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table's kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)

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

memcgwriteevent_control(): fix a user-triggerable oops

we are not guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).(CVE-2024-45021)

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

gtp: fix a potential NULL pointer dereference

When sockfdlookup() fails, gtpencapenablesocket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case.

Fix it by returning an error pointer with the error code carried from sockfd_lookup().

(I found this bug during code inspection.)(CVE-2024-46677)

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

drm/amd/display: Check BIOS images before it is used

BIOS images may fail to load and null checks are added before they are used.

This fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)

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

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

• Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)

• At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)

• At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections

• From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.

• Send some data in both directions.

• Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.(CVE-2024-47659)

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

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries. Hence _fsnotifyupdatechilddentryflags() function can take a significant amount of time. Since the bulk of this function happens under inode->ilock this causes a significant contention on the lock when we remove the watch from the directory as the _fsnotifyupdatechilddentryflags() call from fsnotifyrecalcmask() races with _fsnotifyupdatechilddentryflags() calls from _fsnotifyparent() happening on children. This can lead upto softlockup reports reported by users.

Fix the problem by calling fsnotifyupdatechildrendentryflags() to set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENTWATCHED flags lazily in _fsnotify_parent() for each accessed child.(CVE-2024-47660)

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

lib/generic-radix-tree.c: Fix rare race in _genradixptr_alloc()

If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later.

If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.(CVE-2024-47668)

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

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING.

bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwltranssendcmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwltranssendcmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwlmvmsendcmd+0x40/0xc0 [iwlmvm] iwlmvmconfigscan+0x198/0x260 [iwlmvm] iwlmvmrecalctcm+0x730/0x11d0 [iwlmvm] iwlmvmtcmwork+0x1d/0x30 [iwlmvm] processonework+0x29e/0x640 workerthread+0x2df/0x690 ? rescuerthread+0x540/0x540 kthread+0x192/0x1e0 ? setkthreadstruct+0x90/0x90 retfromfork+0x22/0x30(CVE-2024-47673)

In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fsevictinode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 disposelist fs/inode.c:747 [inline] evictinodes+0x5f9/0x690 fs/inode.c:797 genericshutdownsuper+0x9d/0x2d0 fs/super.c:627 killblocksuper+0x44/0x90 fs/super.c:1696 killf2fssuper+0x344/0x690 fs/f2fs/super.c:4898 deactivatelockedsuper+0xc4/0x130 fs/super.c:473 cleanupmnt+0x41f/0x4b0 fs/namespace.c:1373 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 ptracenotify+0x2d2/0x380 kernel/signal.c:2402 ptracereportsyscall include/linux/ptrace.h:415 [inline] ptracereportsyscallexit include/linux/ptrace.h:477 [inline] syscallexitwork+0xc6/0x190 kernel/entry/common.c:173 syscallexittousermodeprepare kernel/entry/common.c:200 [inline] _syscallexittousermodework kernel/entry/common.c:205 [inline] syscallexittousermode+0x279/0x370 kernel/entry/common.c:218 dosyscall64+0x100/0x230 arch/x86/entry/common.c:89 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0010:f2fsevictinode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fslookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fsstopgcthread() syzbot reports a f2fs bug as below: _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printreport+0xe8/0x550 mm/kasan/report.c:491 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchaddrelaxed include/linux/atomic/atomic-instrumented.h:252 [inline] _refcountadd include/linux/refcount.h:184 [inline] _refcountinc include/linux/refcount.h:241 [inline] refcountinc include/linux/refcount.h:258 [inline] gettaskstruct include/linux/sched/task.h:118 [inline] kthreadstop+0xca/0x630 kernel/kthread.c:704 f2fsstopgcthread+0x65/0xb0 fs/f2fs/gc.c:210 f2fsdoshutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fsiocshutdown fs/f2fs/file.c:2325 [inline] _f2fsioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 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:83 entrySYSCALL64afterhwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gcth pointer. - remount - f2fsremount - f2fsstopgcthread - kfree(gcth) - f2fsiocshutdown - f2fsdoshutdown - f2fsstopgcthread - kthreadstop(gcth->f2fsgctask) : sbi->gcthread = NULL; We will call f2fsdoshutdown() in two paths: - for f2fsiocshutdown() path, we should grab sb->sumount semaphore for fixing. - for f2fsshutdown() path, it's safe since caller has already grabbed sb->sumount semaphore.(CVE-2024-47691)

In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ibcachesetupone error flow cleanup When ibcacheupdate return an error, we exit ibcachesetupone instantly with no proper cleanup, even though before this we had already successfully done gidtablesetupone, that results in the kernel WARN below. Do proper cleanup using gidtablecleanupone before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gidtablereleaseone+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: crepro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gidtablereleaseone+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0x94/0xa0 ? warn+0x9e/0x1c0 ? gidtablereleaseone+0x181/0x1a0 ? reportbug+0x1f9/0x340 ? gidtablereleaseone+0x181/0x1a0 ? handlebug+0xa2/0x110 ? excinvalidop+0x31/0xa0 ? asmexcinvalidop+0x16/0x20 ? _warnprintk+0xc7/0x180 ? _warnprintk+0xd4/0x180 ? gidtablereleaseone+0x181/0x1a0 ibdevicerelease+0x71/0xe0 ? _pfxibdevicerelease+0x10/0x10 devicerelease+0x44/0xd0 kobjectput+0x135/0x3d0 putdevice+0x20/0x30 rxenetadd+0x7d/0xa0 rxenewlink+0xd7/0x190 nldevnewlink+0x1b0/0x2a0 ? _pfxnldevnewlink+0x10/0x10 rdmanlrcvmsg+0x1ad/0x2e0 rdmanlrcvskb.constprop.0+0x176/0x210 netlinkunicast+0x2de/0x400 netlinksendmsg+0x306/0x660 _socksendmsg+0x110/0x120 syssendmsg+0x30e/0x390 _syssendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouintfromuser+0x7c/0xb0 ? getpidtask+0xb0/0xd0 ? procfailnthwrite+0x5b/0x140 ? _fgetlight+0x9a/0x200 ? preemptcountadd+0x47/0xa0 _syssendmsg+0x61/0xd0 dosyscall64+0x50/0x110 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-47693)

In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:atkernel/workqueue.c:#checkflushdependency In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flushworkqueue is invoked to flush the work queue iwcmwq. But at that time, the work queue iwcmwq was created via the function allocorderedworkqueue without the flag WQMEMRECLAIM. Because the current process is trying to flush the whole iwcmwq, if iwcmwq doesn't have the flag WQMEMRECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQMEMRECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? warn (kernel/panic.c:693) [ 125.367640][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? reportbug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handlebug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asmexcinvalidop (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] _flushworkqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? _pfxmightresched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroycmid (drivers/infiniband/core/iwcm.c:375) iwcm [ 125.441209][ T1430] ? pfxflushworkqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _rawspinlockirqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlockapismp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? pfxrawspinlockirqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroyid (drivers/infiniband/core/cma.c:2044) rdmacm [ 125.495072][ T1430] nvmerdmafreequeue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvmerdma [ 125.505827][ T1430] nvmerdmaresetctrlwork (drivers/nvme/host/rdma.c:2180) nvmerdma [ 125.505831][ T1430] processonework (kernel/workqueue.c:3231) [ 125.515122][ T1430] workerthread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? _pfxworkerthread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.550628][ T1430] retfromfork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.558844][ T1430] retfromforkasm (arch/x86/entry/entry64.S:257) [ 125.566487][ T1430] </TASK> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfsbtreeinsert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfsbtreeprepareinsert(), which is called from nilfsbtreeinsert(). This is because, when the number of child nodes of the b-tree root is 0, nilfsbtreedolookup() does not set the block buffer head in any of path[x].bpbh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfsbtreegetnonrootnode(), which accesses the buffer memory of path[x].bpbh, is called. Fix this issue by adding a check to nilfsbtreeroot_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if evalueoffs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 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 kasanreport+0x143/0x180 mm/kasan/report.c:601 ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4findinlineentry+0x4be/0x5e0 fs/ext4/inline.c:1697 _ext4findentry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4lookupentry fs/ext4/namei.c:1727 [inline] ext4lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookuponeqstrexcl+0x11f/0x260 fs/namei.c:1633 filenamecreate+0x297/0x540 fs/namei.c:3980 dosymlinkat+0xf9/0x3a0 fs/namei.c:4587 _dosyssymlinkat fs/namei.c:4610 [inline] _sesyssymlinkat fs/namei.c:4607 [inline] _x64syssymlinkat+0x95/0xb0 fs/namei.c:4607 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIGRAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4xattribodyfind right after reading the inode with ext4getinodeloc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)

In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to fileallocsecurity hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using ISERR, and misinterprets this positive number as a file pointer. Given that hook filealloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)

In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blkaddpartition The blkaddpartition() function initially used a single if-condition (ISERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where mdautodetectdev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of mdautodetect_dev() calls.(CVE-2024-47705)

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->dbnumag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->dbnumag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)

In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seqnr overflow When submitting more than 2^32 padata objects to padatadoserial, the current sorting implementation incorrectly sorts padata objects with overflowed seqnr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padatafindnext cannot match padata->seqnr and pd->processed because the padata instance with overflowed seqnr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)

In the Linux kernel, the following vulnerability has been resolved: firmwareloader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfcsli4requestfirmwareupdate() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfcfillvpd() - nfpnetfwfind() seems to construct a firmware filename from a model name coming from nfphwinfolookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic%s", and there shouldn't be any *folders* starting with "netronome/nic". The previous case was different because there, the "%s" is at the start of the format string.) - moduleflashfwschedule() is reachable from the ETHTOOLMSGMODULEFWFLASHACT netlink command, which is marked as GENLUNSADMINPERM (meaning CAPNETADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAPNET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)

In the Linux kernel, the following vulnerability has been resolved: vhostvdpa: assign irq bypass producer token correctly We used to call irqbypassunregisterproducer() in vhostvdpasetupvqirq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfdctx as the token so the life cycle of the token should be bound to the VHOSTSETVRINGCALL instead of vhostvdpasetupvqirq() which could be called by setstatus(). Fixing this by setting up irq bypass producer's token when handling VHOSTSETVRINGCALL and un-registering the producer before calling vhostvringioctl() to prevent a possible use after free as eventfd could have been released in vhostvringioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in kspciequirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. kwilczynski: commit log

In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)

In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFILOADERDATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFIACPIRECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomicfile in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fsiocsetpinfile(), f2fsmovefilerange(), and f2fsdefragmentrange() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)

In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of STR method Only buffer objects are valid return values of _STR. If something else is returned descriptionshow() will access invalid memory.(CVE-2024-49860)

In the Linux kernel, the following vulnerability has been resolved: powercap: intelrapl: Fix off by one in getrpi() The rp->priv->rpi array is either rpimsr or rpitpmi which have NRRAPLPRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.(CVE-2024-49862)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2setbufferuptodate When doing cleanup, if flags without OCFS2BHREADAHEAD, it may trigger NULL pointer dereference in the following ocfs2setbufferuptodate() if bh is NULL.(CVE-2024-49877)

In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for allocorderedworkqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of allocorderedworkqueue.(CVE-2024-49879)

In the Linux kernel, the following vulnerability has been resolved: ext4: update origpath in ext4findextent() In ext4findextent(), if the path is not big enough, we free it and set *origpath to NULL. But after reallocating and successfully initializing the path, we don't update orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(ppath = NULL) path = *ppath; ex = path[depth].pext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4splitextentat+0x6d/0x560 Call Trace: <TASK> ext4splitextent.isra.0+0xcb/0x1b0 ext4extconverttoinitialized+0x168/0x6c0 ext4exthandleunwrittenextents+0x325/0x4d0 ext4extmapblocks+0x520/0xdb0 ext4mapblocks+0x2b0/0x690 ext4iomapbegin+0x20e/0x2c0 [...] ================================================================== Therefore, *origpath is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4exttrytomergeup(), set path[1].pbh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4extmapblocks ext4exthandleunwrittenextents ext4splitconvertextents // path->pdepth == 0 ext4splitextent // 1. do split1 ext4splitextentat |ext4extinsertextent | ext4extcreatenewleaf | ext4extgrowindepth | le16addcpu(&neh->ehdepth, 1) | ext4findextent | // return -ENOMEM |// get error and try zeroout |path = ext4findextent | path->pdepth = 1 |ext4exttrytomerge | ext4exttrytomergeup | path->pdepth = 0 | brelse(path[1].pbh) ---> not set to NULL here |// zeroout success // 2. update path ext4findextent // 3. do split2 ext4splitextentat ext4extinsertextent ext4extcreatenewleaf ext4extgrowindepth le16addcpu(&neh->ehdepth, 1) ext4findextent path[0].pbh = NULL; path->pdepth = 1 readextenttreeblock ---> return err // path[1].pbh is still the old value ext4freeextpath ext4extdroprefs // path->pdepth == 1 brelse(path[1].pbh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:brelse+0x58/0x90 Call Trace: <TASK> _findgetblock+0x6e7/0x810 bdevgetblk+0x2b/0x480 _ext4getinodeloc+0x48a/0x1240 ext4getinodeloc+0xb2/0x150 ext4reserveinodewrite+0xb7/0x230 _ext4markinodedirty+0x144/0x6a0 ext4extinsertextent+0x9c8/0x3230 ext4extmapblocks+0xf45/0x2dc0 ext4mapblocks+0x724/0x1700 ext4do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)

In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4extinsertextent() As Ojaswin mentioned in Link, in ext4extinsertextent(), if the path is reallocated in ext4extcreatenewleaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4extinsertextent path = *ppath = 2000 ext4extcreatenewleaf(ppath) ext4findextent(ppath) path = *ppath = 2000 if (depth > path[0].pmaxdepth) kfree(path = 2000); ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; / here path is still 2000, UAF! */ eh = path[depth].phdr ================================================================== BUG: KASAN: slab-use-after-free in ext4extinsertextent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4extinsertextent+0x26d4/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 [...] Allocated by task 179: ext4findextent+0x81c/0x1f70 ext4extmapblocks+0x146/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 dowritepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4findextent+0x7c0/0x1f70 ext4extinsertextent+0xa26/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4splitextentat() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4splitextentat+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: <TASK> kasanreport+0x93/0xc0 ext4splitextentat+0xba8/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Allocated by task 40: _kmallocnoprof+0x1ac/0x480 ext4findextent+0xf3b/0x1e70 ext4extmapblocks+0x188/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4findextent+0xa71/0x1e70 ext4extinsertextent+0xa22/0x3260 ext4splitextentat+0x3ef/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4splitextentat path = *ppath ext4extinsertextent(ppath) ext4extcreatenewleaf(ppath) ext4findextent(origpath) path = *origpath readextenttreeblock // return -ENOMEM or -EIO ext4freeextpath(path) kfree(path) *origpath = NULL a. If err is -ENOMEM: ext4extdirty(path + path->pdepth) // path use-after-free !!! b. If err is -EIO and we have EXTDEBUG defined: ext4extshowleaf(path) eh = path[depth].phdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4findextent() to update the path. In addition we use *ppath directly as an ext4extshowleaf() input to avoid possible use-after-free when EXTDEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] <TASK> [ 19.425448] dumpstacklvl+0x5d/0x80 [ 19.426963] ? _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.428694] printreport+0x19d/0x52e [ 19.430206] ? pfxrawspinlockirqsave+0x10/0x10 [ 19.431837] ? _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.433539] kasanreport+0xf0/0x170 [ 19.435019] ? isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.436709] _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.438379] ? _pfxschedclockcpu+0x10/0x10 [ 19.439910] isstifcpuonline+0x406/0x58f [isstifcommon] [ 19.441573] ? _pfxisstifcpuonline+0x10/0x10 [isstifcommon] [ 19.443263] ? ttwuqueuewakelist+0x2c1/0x360 [ 19.444797] cpuhpinvokecallback+0x221/0xec0 [ 19.446337] cpuhpthreadfun+0x21b/0x610 [ 19.447814] ? _pfxcpuhpthreadfun+0x10/0x10 [ 19.449354] smpbootthreadfn+0x2e7/0x6e0 [ 19.450859] ? _pfxsmpbootthreadfn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? _pfxkthread+0x10/0x10 [ 19.455253] retfromfork+0x31/0x70 [ 19.456685] ? _pfxkthread+0x10/0x10 [ 19.458114] retfromforkasm+0x1a/0x30 [ 19.459573] </TASK> [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasansavestack+0x30/0x50 [ 19.464788] kasansavetrack+0x14/0x30 [ 19.466139] _kasankmalloc+0xaa/0xb0 [ 19.467465] _kmalloc+0x1cd/0x470 [ 19.468748] isstifcdevregister+0x1da/0x350 [isstifcommon] [ 19.470233] isstifmboxinit+0x108/0xff0 [isstifmboxmsr] [ 19.471670] dooneinitcall+0xa4/0x380 [ 19.472903] doinitmodule+0x238/0x760 [ 19.474105] loadmodule+0x5239/0x6f00 [ 19.475285] initmodulefromfile+0xd1/0x130 [ 19.476506] idempotentinitmodule+0x23b/0x650 [ 19.477725] _x64sysfinitmodule+0xbe/0x130 [ 19.476506] idempotentinitmodule+0x23b/0x650 [ 19.477725] _x64sysfinitmodule+0xbe/0x130 [ 19.478920] dosyscall64+0x82/0x160 [ 19.480036] entrySYSCALL64afterhwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] pagetype: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---(CVE-2024-49886)

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4extshowleaf() In ext4findextent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4splitextent path = *ppath; ext4splitextentat(ppath) path = ext4findextent(ppath) ext4splitextentat(ppath) // ext4findextent fails to free path // but zeroout succeeds ext4extshowleaf(inode, path) eh = path[depth].phdr // path use-after-free !!! Similar to ext4splitextentat(), we use *ppath directly as an input to ext4extshowleaf(). Fix a spelling error by the way. Same problem in ext4exthandleunwrittenextents(). Since 'path' is only used in ext4extshowleaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpudm can pass a null stream to dcisstreamunchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for toppipetoprogram in commitplanesforstream This commit addresses a null pointer dereference issue in the commit_planes_for_stream function at line 4140. The issue could occur when top_pipe_to_program is null. The fix adds a check to ensure top_pipe_to_program is not null before accessing its streamres. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commitplanesforstream() error: we previously assumed 'toppipeto_program' could be null (see line 3906)(CVE-2024-49913)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clkmgr and clkmgr->funcs in dcn30inithw This commit addresses a potential null pointer dereference issue in the dcn30_init_hw function. The issue could occur when dc->clk_mgr or dc->clk_mgr->funcs is null. The fix adds a check to ensure dc->clk_mgr and dc->clk_mgr->funcs is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:789 dcn30inithw() error: we previously assumed 'dc->clkmgr' could be null (see line 628)(CVE-2024-49917)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)

In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafbtask() In the pxafbprobe function, it calls the pxafbinitfbinfo function, after which &fbi->task is associated with pxafbtask. Moreover, within this pxafbinitfbinfo function, the pxafbblank function within the &pxafbops struct is capable of scheduling work. If we remove the module which will call pxafbremove to make cleanup, it will call unregisterframebuffer function which can call dounregisterframebuffer to free fbi->fb through putfbinfo(fbinfo), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafbtask pxafbremove | unregisterframebuffer(info) | dounregisterframebuffer(fbinfo) | putfbinfo(fbinfo) | // free fbi->fb | setctrlrstate(fbi, state) | _pxafblcdpower(fbi, 0) | fbi->lcdpower(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafbremove. Note that only root user can remove the driver at runtime.(CVE-2024-49924)

In the Linux kernel, the following vulnerability has been resolved: blkiocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the iocforgivedebts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> dumpstacklvl+0xca/0x130 _ubsanhandleshiftoutofbounds+0x22c/0x280 ? _lockacquire+0x6441/0x7c10 ioctimerfn+0x6cec/0x7750 ? blkiocostinit+0x720/0x720 ? calltimerfn+0x5d/0x470 calltimerfn+0xfa/0x470 ? blkiocostinit+0x720/0x720 _runtimerbase+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)

In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dumpmapping() accessing invalid dentry.dname.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 douseraddrfault+0x2a0/0x790 Modules linked in: kmem devicedax cxlmem cxlpmem cxlport cxlpci daxhmem daxpmem ndpmem cxlacpi ndbtt cxlcore crc32cintel nvme virtiofs fuse nvmecore nfit libnvdimm dmmultipath scsidhrdac scsidhemc s mirror dmregionhash dmlog dmmod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:douseraddrfault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _warn+0x8d/0x190 ? douseraddrfault+0x2a0/0x790 ? reportbug+0x1c3/0x1d0 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? douseraddrfault+0x2a0/0x790 ? excpagefault+0x31/0x200 excpagefault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentryname+0x1f4/0x440 <...snip...> ? dentryname+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintkstore+0x23a/0x540 vprintkemit+0x6d/0x330 printk+0x58/0x80 dumpmapping+0x10b/0x1a0 ? _pfxfreeobjectrcu+0x10/0x10 _dumppage+0x26b/0x3e0 ? vprintkemit+0xe0/0x330 ? _printk+0x58/0x80 ? dumppage+0x17/0x50 dumppage+0x17/0x50 domigraterange+0x2f7/0x7f0 ? domigraterange+0x42/0x7f0 ? offlinepages+0x2f4/0x8c0 offlinepages+0x60a/0x8c0 memorysubsysoffline+0x9f/0x1c0 ? lockdephardirqson+0x77/0x100 ? _rawspinunlockirqrestore+0x38/0x60 deviceoffline+0xe3/0x110 statestore+0x6e/0xc0 kernfsfopwriteiter+0x143/0x200 vfswrite+0x39f/0x560 ksyswrite+0x65/0xf0 dosyscall64+0x62/0x130 Previously, some sanity check have been done in dumpmapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.dname.name. Since dumpmapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpyfromkernel_nofault(), the filename could be unreliable.(CVE-2024-49934)

In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvifflushhash() During the listforeachentryrcu iteration call of xenvifflushhash, kfreercu does not exist inside the rcu read critical section, so if kfreercu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to listforeachentrysafe.(CVE-2024-49936)

In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tpsessionfree drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tpsessioncreate, before the tunnel refcount is incremented by l2tpsessionregister, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tpsessionregister is trivial but l2tpsessioncreate calls l2tpsessionsetheaderlen which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tpsessionsetheaderlen to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tpv3sessionget to race with l2tpsession_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.(CVE-2024-49940)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2capconnect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2capconnect.constprop.0+0x10d8/0x1270 net/bluetooth/l2capcore.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hcirxwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 l2capconnect.constprop.0+0x10d8/0x1270 net/bluetooth/l2capcore.c:3949 l2capconnectreq net/bluetooth/l2capcore.c:4080 [inline] l2capbredrsigcmd net/bluetooth/l2capcore.c:4772 [inline] l2capsigchannel net/bluetooth/l2capcore.c:5543 [inline] l2caprecvframe+0xf0b/0x8eb0 net/bluetooth/l2capcore.c:6825 l2caprecvacldata+0x9b4/0xb70 net/bluetooth/l2capcore.c:7514 hciacldatapacket net/bluetooth/hcicore.c:3791 [inline] hcirxwork+0xaab/0x1610 net/bluetooth/hcicore.c:4028 processonework+0x9c5/0x1b40 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xed0 kernel/workqueue.c:3389 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 ... Freed by task 5245: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:579 poisonslabobject+0xf7/0x160 mm/kasan/common.c:240 _kasanslabfree+0x32/0x50 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+0x12a/0x3b0 mm/slub.c:4598 l2capconnfree net/bluetooth/l2capcore.c:1810 [inline] krefput include/linux/kref.h:65 [inline] l2capconnput net/bluetooth/l2capcore.c:1822 [inline] l2capconndel+0x59d/0x730 net/bluetooth/l2capcore.c:1802 l2capconnectcfm+0x9e6/0xf80 net/bluetooth/l2capcore.c:7241 hciconnectcfm include/net/bluetooth/hcicore.h:1960 [inline] hciconnfailed+0x1c3/0x370 net/bluetooth/hciconn.c:1265 hciabortconnsync+0x75a/0xb50 net/bluetooth/hcisync.c:5583 abortconnsync+0x197/0x360 net/bluetooth/hciconn.c:2917 hcicmdsyncwork+0x1a4/0x410 net/bluetooth/hcisync.c:328 processonework+0x9c5/0x1b40 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xed0 kernel/workqueue.c:3389 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-49950)

In the Linux kernel, the following vulnerability has been resolved: staticcall: Replace pointless WARNON() in staticcallmodulenotify() staticcallmodulenotify() triggers a WARNON(), when memory allocation fails in _staticcalladdmodule(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARNON() takes the machine out when paniconwarn is set. Replace it with a pr_warn().(CVE-2024-49954)

In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call batteryhookunregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by batteryhookunregister().(CVE-2024-49955)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENTLISTFREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2reflinkxattrinline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the lcount from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)

In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)

In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xoladdvma() maps the uninitialized page allocated by _createxolarea() into userspace. On some architectures (x86) this memory is readable even without VMREAD, VMEXEC results in the same pgprott as VMEXEC|VMREAD, although this doesn't really matter, debugger can read this memory anyway.(CVE-2024-49975)

In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from fraglist Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skbsegment instead of skbsegmentlist, as the first can segment them correctly. Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in _udpv4gsosegmentlistcsum at udphdr(seg->next)->dest. Detect invalid geometry due to pull, by checking headskb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venusremove due to race condition in venusprobe, core->work is bound with venussyserrorhandler, which is used to handle error. The code use core->syserrdone to make sync work. The core->work is started in venuseventnotify. If we call venusremove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venussyserrorhandler venusremove | hfidestroy | venushfidestroy | kfree(hdev); | |hfireinit |venushfiqueuesreinit |//use hdev Fix it by canceling the work in venusremove.(CVE-2024-49981)

In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdcload() calls functions drmcrtcinitwithplanes(), drmuniversalplaneinit() and drmencoderinit(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)

In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying medianame and ifname to nameparts may overwrite the destination. .../bearer.c:166 bearernamevalidate() error: strcpy() 'medianame' too large for 'nameparts->medianame' (32 vs 16) .../bearer.c:167 bearernamevalidate() error: strcpy() 'ifname' too large for 'nameparts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge") Compile tested only.(CVE-2024-49995)

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifsstrndupfromutf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparsemkdev().(CVE-2024-49996)

In the Linux kernel, the following vulnerability has been resolved: staticcall: Handle module init failure correctly in staticcalldelmodule() Module insertion invokes staticcalladdmodule() to initialize the static calls in a module. staticcalladdmodule() invokes _staticcallinit(), which allocates a struct staticcallmod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes staticcalldelmodule() to clean up eventually added staticcallmod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then staticcalldelmodule() causes a #GP as it blindly assumes that key::mods points to a valid struct staticcallmod. The problem is that key::mods is not a individual struct member of struct staticcallkey, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct staticcallmod *mods; struct staticcallsite *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As staticcalldelmodule() blidly assumes that the pointer is a valid staticcallmod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in _staticcallinit() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in _staticcallinit() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of staticcalldelmodule() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a staticcallsite pointer and not a staticcall_mod pointer.(CVE-2024-50002)

In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexcmd80211scanext() Replace one-element array with a flexible-array member in struct host_cmd_ds_802_11_scan_ext. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "extscan->tlvbuffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiexcmd80211scanext+0x83/0x90 mwifiex

In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The daxiomaprw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in daxiomapiter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 daxiomaprw iomapiter // round 1 ext4iomapbegin ext4iomapalloc // allocate 0~2M extents(written flag) daxiomapiter // copy 2M data iomapiter // round 2 iomapiteradvance iter->pos += iter->processed // iter->pos = 2M ext4iomapbegin ext4iomapalloc // allocate 2~4M extents(written flag) daxiomapiter fatalsignalpending done = iter->pos - iocb->kipos // done = 2M ext4handleinodeextension ext4updateinodesize // inode size = 2M fsck reports: Inode 13, isize is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in linkdpcts samplingrate is an uint8t but is assigned an unsigned int, and thus it can overflow. As a result, samplingrate is changed to uint32t. Similarly, LINKQUALPATTERNSET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGEROVERFLOW issues reported by Coverity.(CVE-2024-50016)

In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermalzonegetbyid() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermalzonegetbyid(). To address this, make thermalzonegetbyid() get a reference on the thermal zone device object to be returned with the help of getdevice(), under thermallist_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)

In the Linux kernel, the following vulnerability has been resolved: slip: make slhcremember() more robust against malicious packets syzbot found that slhcremember() was missing checks against malicious packets [1]. slhcremember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 pppreceivenonmpframe+0xe45/0x35e0 drivers/net/ppp/pppgeneric.c:2455 pppreceiveframe drivers/net/ppp/pppgeneric.c:2372 [inline] pppdorecv+0x65f/0x40d0 drivers/net/ppp/pppgeneric.c:2212 pppinput+0x7dc/0xe60 drivers/net/ppp/pppgeneric.c:2327 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Uninit was created at: slabpostallochook mm/slub.c:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 _syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)

In the Linux kernel, the following vulnerability has been resolved: ppp: fix pppasyncencode() illegal access syzbot reported an issue in pppasyncencode() [1] In this case, pppoesendmsg() is called with a zero size. Then pppasyncencode() is called with an empty skb. BUG: KMSAN: uninit-value in pppasyncencode drivers/net/ppp/pppasync.c:545 [inline] BUG: KMSAN: uninit-value in pppasyncpush+0xb4f/0x2660 drivers/net/ppp/pppasync.c:675 pppasyncencode drivers/net/ppp/pppasync.c:545 [inline] pppasyncpush+0xb4f/0x2660 drivers/net/ppp/pppasync.c:675 pppasyncsend+0x130/0x1b0 drivers/net/ppp/pppasync.c:634 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2280 [inline] pppinput+0x1f1/0xe60 drivers/net/ppp/pppgeneric.c:2304 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 _syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Uninit was created at: slabpostallochook mm/slub.c:4092 [inline] slaballocnode mm/slub.c:4135 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4187 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 _syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)

In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 ("igb: Fix igbdown hung on surprise removal") changed igbioerrordetected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igbdown() is called multiple times. This caused an issue when processing transient non-fatal errors. igbioresume(), which is called after igbioerrordetected(), assumes that device is brought down by igbioerrordetected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast errordetected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmioenabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napienable+0x37/0x40 [ T292] Call Trace: [ T292] <TASK> [ T292] ? die+0x33/0x90 [ T292] ? dotrap+0xdc/0x110 [ T292] ? napienable+0x37/0x40 [ T292] ? doerrortrap+0x70/0xb0 [ T292] ? napienable+0x37/0x40 [ T292] ? napienable+0x37/0x40 [ T292] ? excinvalidop+0x4e/0x70 [ T292] ? napienable+0x37/0x40 [ T292] ? asmexcinvalidop+0x16/0x20 [ T292] ? napienable+0x37/0x40 [ T292] igbup+0x41/0x150 [ T292] igbioresume+0x25/0x70 [ T292] reportresume+0x54/0x70 [ T292] ? reportfrozendetected+0x20/0x20 [ T292] pciwalkbus+0x6c/0x90 [ T292] ? aerprintportinfo+0xa0/0xa0 [ T292] pciedorecovery+0x22f/0x380 [ T292] aerprocesserrdevices+0x110/0x160 [ T292] aerisr+0x1c1/0x1e0 [ T292] ? disableirqnosync+0x10/0x10 [ T292] irqthreadfn+0x1a/0x60 [ T292] irqthread+0xe3/0x1a0 [ T292] ? irqsetaffinitynotifier+0x120/0x120 [ T292] ? irqaffinitynotify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromfork+0x2d/0x50 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromforkasm+0x11/0x20 [ T292] </TASK> To fix this issue igbioresume() checks if the interface is running and the device is not down this means igbioerrordetected() did not bring the device down and there is no need to bring it up.(CVE-2024-50040)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul4klle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2decryptoffload [cifs] [ 194.200032] Call Trace: [ 194.200191] <TASK> [ 194.200327] dumpstacklvl+0x4e/0x70 [ 194.200558] ? gf128mul4klle+0xc1/0x110 [ 194.200809] printreport+0x174/0x505 [ 194.201040] ? pfxrawspinlockirqsave+0x10/0x10 [ 194.201352] ? srsoreturnthunk+0x5/0x5f [ 194.201604] ? _virtaddrvalid+0xdf/0x1c0 [ 194.201868] ? gf128mul4klle+0xc1/0x110 [ 194.202128] kasanreport+0xc8/0x150 [ 194.202361] ? gf128mul4klle+0xc1/0x110 [ 194.202616] gf128mul4klle+0xc1/0x110 [ 194.202863] ghashupdate+0x184/0x210 [ 194.203103] shashahashupdate+0x184/0x2a0 [ 194.203377] ? _pfxshashahashupdate+0x10/0x10 [ 194.203651] ? srsoreturnthunk+0x5/0x5f [ 194.203877] ? cryptogcminitcommon+0x1ba/0x340 [ 194.204142] gcmhashassocremaincontinue+0x10a/0x140 [ 194.204434] cryptmessage+0xec1/0x10a0 [cifs] [ 194.206489] ? _pfxcryptmessage+0x10/0x10 [cifs] [ 194.208507] ? srsoreturnthunk+0x5/0x5f [ 194.209205] ? srsoreturnthunk+0x5/0x5f [ 194.209925] ? srsoreturnthunk+0x5/0x5f [ 194.210443] ? srsoreturnthunk+0x5/0x5f [ 194.211037] decryptrawdata+0x15f/0x250 [cifs] [ 194.212906] ? _pfxdecryptrawdata+0x10/0x10 [cifs] [ 194.214670] ? srsoreturnthunk+0x5/0x5f [ 194.215193] smb2decryptoffload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3calcsignature()). Also remove the calls to aeadrequestsetcallback() and cryptowait_req() since it's always going to be a synchronous operation.(CVE-2024-50047)

In the Linux kernel, the following vulnerability has been resolved: serial: protect uartportdtrrts() in uartshutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uartshutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uartportdtrrts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)

In the Linux kernel, the following vulnerability has been resolved: ntb: ntbhwswitchtec: Fix use after free vulnerability in switchtecntbremove due to race condition In the switchtecntbadd function, it can call switchtecntbinitsndev function, then &sndev->checklinkstatuswork is bound with checklinkstatuswork. switchtecntblinknotification may be called to start the work. If we remove the module which will call switchtecntbremove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | checklinkstatuswork switchtecntbremove | kfree(sndev); | | if (sndev->linkforcedown) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtecntb_remove.(CVE-2024-50059)

In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)

In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook fileallocsecurity, and BPF LSM prog2 is attached to hook bpflsmauditruleknown. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpflsmauditruleknown to return positive number 1, and it is illegal for fileallocsecurity to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook fileallocsecurity. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)

In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org(CVE-2024-50064)

In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And storetraceargs() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIGKASAN enabled 2. save follow program as test.c \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } 3. compile program gcc -o test test.c 4. get the offset of print_string() objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string 5. configure uprobe with offset 0x1199 off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on 6. run test, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpyfromuser+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x27/0x310 kasanreport+0x10f/0x120 ? strncpyfromuser+0x1d6/0x1f0 strncpyfromuser+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 processfetchinsn+0xb26/0x1470 ? pfxprocessfetchinsn+0x10/0x10 ? _rawspinlock+0x85/0xe0 ? _pfxrawspinlock+0x10/0x10 ? pteoffsetmap+0x1f/0x2d0 ? unwindnextframe+0xc5f/0x1f80 ? archstackwalk+0x68/0xf0 ? isbpftextaddress+0x23/0x30 ? kerneltextaddress.part.0+0xbb/0xd0 ? _kerneltextaddress+0x66/0xb0 ? unwindgetreturnaddress+0x5e/0xa0 ? _pfxstacktraceconsumeentry+0x10/0x10 ? archstackwalk+0xa2/0xf0 ? rawspinlockirqsave+0x8b/0xf0 ? _pfxrawspinlockirqsave+0x10/0x10 ? depotallocstack+0x4c/0x1f0 ? rawspinunlockirqrestore+0xe/0x30 ? stackdepotsaveflags+0x35d/0x4f0 ? kasansavestack+0x34/0x50 ? kasansavestack+0x24/0x50 ? mutexlock+0x91/0xe0 ? _pfxmutexlock+0x10/0x10 prepareuprobebuffer.part.0+0x2cd/0x500 uprobedispatcher+0x2c3/0x6a0 ? _pfxuprobedispatcher+0x10/0x10 ? _kasanslaballoc+0x4d/0x90 handlerchain+0xdd/0x3e0 handleswbp+0x26e/0x3d0 ? _pfxhandleswbp+0x10/0x10 ? uprobepresstepnotifier+0x151/0x1b0 irqentryexittousermode+0xe2/0x1b0 asmexcint3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> This commit enforces the buffer's maxlen less than a page-size to avoid storetraceargs() out-of-memory access.(CVE-2024-50067)

In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)

In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: requestsocksubflowv4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 mptcpmoveskbsfromsubflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:mptcpmoveskbsfromsubflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> moveskbstomsk net/mptcp/protocol.c:811 [inline] mptcpdataready+0x29c/0xa90 net/mptcp/protocol.c:854 subflowdataready+0x34a/0x920 net/mptcp/subflow.c:1490 tcpdataqueue+0x20fd/0x76c0 net/ipv4/tcpinput.c:5283 tcprcvestablished+0xfba/0x2020 net/ipv4/tcpinput.c:6237 tcpv4dorcv+0x96d/0xc70 net/ipv4/tcpipv4.c:1915 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2350 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:5662 [inline] _netifreceiveskb+0x2bf/0x650 net/core/dev.c:5775 processbacklog+0x662/0x15b0 net/core/dev.c:6107 _napipoll+0xcb/0x490 net/core/dev.c:6771 napipoll net/core/dev.c:6840 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:6962 handlesoftirqs+0x2c5/0x980 kernel/softirq.c:554 dosoftirq+0x11b/0x1e0 kernel/softirq.c:455 </IRQ> <TASK> _localbhenableip+0x1bb/0x200 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] _devqueuexmit+0x1764/0x3e80 net/core/dev.c:4451 devqueuexmit include/linux/netdevice.h:3094 [inline] neighhhoutput include/net/neighbour.h:526 [inline] neighoutput include/net/neighbour.h:540 [inline] ipfinishoutput2+0xd41/0x1390 net/ipv4/ipoutput.c:236 iplocalout net/ipv4/ipoutput.c:130 [inline] _ipqueuexmit+0x118c/0x1b80 net/ipv4/ipoutput.c:536 _tcptransmitskb+0x2544/0x3b30 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpmtuprobe net/ipv4/tcpoutput.c:2547 [inline] tcpwritexmit+0x641d/0x6bf0 net/ipv4/tcpoutput.c:2752 _tcppushpendingframes+0x9b/0x360 net/ipv4/tcpoutput.c:3015 tcppushpendingframes include/net/tcp.h:2107 [inline] tcpdatasndcheck net/ipv4/tcpinput.c:5714 [inline] tcprcvestablished+0x1026/0x2020 net/ipv4/tcpinput.c:6239 tcpv4dorcv+0x96d/0xc70 net/ipv4/tcpipv4.c:1915 skbacklogrcv include/net/sock.h:1113 [inline] _releasesock+0x214/0x350 net/core/sock.c:3072 releasesock+0x61/0x1f0 net/core/sock.c:3626 mptcppush ---truncated---(CVE-2024-50083)