OESA-2024-2426

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

pinctrl: single: fix potential NULL dereference in pcsgetfunction()

pinmuxgenericgetfunction() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcsget_function().

Found by code review.(CVE-2024-46685)

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

thunderbolt: Mark XDomain as unplugged when router is removed

I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tbdisconnectxdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tbstop() so there is really no need for tbdisconnectxdomainpaths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.(CVE-2024-46702)

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

drm/amd/display: Check numvalidsets before accessing readerwmsets[]

[WHY & HOW] numvalidsets needs to be checked to avoid a negative index when accessing readerwmsets[numvalidsets - 1].

This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)

In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between eviceinodes() and findinode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with icount 1 is called by iput(), and there's a concurrent thread calling genericshutdownsuper(). cpu0: cpu1: iput() // icount is 1 ->spinlock(inode) ->dec icount to 0 ->iputfinal() genericshutdownsuper() ->inodeaddlru() ->evictinodes() // cause some reason[2] ->if (atomicread(inode->icount)) continue; // return before // inode 261 passed the above check // listlruaddobj() // and then schedule out ->spinunlock() // note here: the inode 261 // was still at sb list and hash list, // and IFREEING|IWILLFREE was not been set btrfsiget() // after some function calls ->findinode() // found the above inode 261 ->spinlock(inode) // check IFREEING|IWILLFREE // and passed ->iget() ->spinunlock(inode) // schedule back ->spinlock(inode) // check (INEW|IFREEING|IWILLFREE) flags, // passed and set IFREEING iput() ->spinunlock(inode) ->spinlock(inode) ->evict() // dec icount to 0 ->iputfinal() ->spinunlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->istate & ICLEAR) statement both within clearinode() and iput(). To fix the bug, recheck the inode->icount after holding ilock. Because in the most scenarios, the first check is valid, and the overhead of spinlock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SBACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)

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: 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: resource: fix regionintersects() vs addmemorydrivermanaged() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls addmemorydrivermanaged() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses regionintersects(), which expects all "System RAM" resources to be at the top level of iomemresource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmemisallowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 _ioremapcaller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlatedevmemptr+0x25/0x2f writemem+0x94/0xfb vfswrite+0x128/0x26d ksyswrite+0xac/0xfe dosyscall64+0x9a/0xfd entrySYSCALL64afterhwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, regionintersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmemisallowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, regionintersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for regionintersects(, IORESOURCESYSTEMRAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".(CVE-2024-49878)

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: net: add more sanity checks to qdiscpktleninit() One path takes care of SKBGSODODGY, assuming skb->len is bigger than hdrlen. virtionethdrtoskb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gsosize like 8 virtionethdrtoskb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gsosize. We need to make detect this case to not underflow qdiscskbcb(skb)->pkt_len.(CVE-2024-49948)

In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdiscpktleninit() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtionethdrtoskb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtionethdrtoskb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKBGSOUDP, gsosize=3, skb->len = 28. When this packet arrives in qdiscpktleninit(), we end up with hdrlen = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gsosegs to 0 : gsosegs = DIVROUNDUP(skb->len - hdrlen, shinfo->gsosize); Then later we set qdiscskbcb(skb)->pktlen to back to zero :/ qdiscskbcb(skb)->pktlen += (gsosegs - 1) * hdrlen; This leads to the following crash in fqcodel [1] qdiscpktleninit() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: errorcode(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fqcodelenqueue (net/sched/schfqcodel.c:120 net/sched/schfqcodel.c:168 net/sched/schfqcodel.c:230) schfq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4fillsuper The deltimersync function cancels the serrreport timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failedmount3, where an error occurs when ext4stopmmpd is called, causing a read I/O failure. This triggers the ext4handleerror function that ultimately re-arms the timer, leaving the serrreport timer active before kfree(sbi) is called. Fix the issue by canceling the serrreport timer after calling ext4stop_mmpd.(CVE-2024-49960)

In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)

In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4extreplayupdateex() to avoid double-free When calling ext4forcesplitextentat() in ext4extreplayupdateex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4extreplayupdateex ppath = path ext4forcesplitextentat(&ppath) ext4splitextentat ext4extinsertextent ext4extcreatenewleaf ext4extgrowindepth ext4findextent if (depth > path[0].pmaxdepth) kfree(path) ---> path First freed *origpath = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4findextent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4find_extent() instead of using strange error codes.(CVE-2024-49983)

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: ext4: fix idatasem unlock order in ext4indmigrate() Fuzzing reports a possible deadlock in jbd2logwaitcommit. This issue is triggered when an EXT4IOCMIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with OSYNC. This can lead to the jbd2journalstop() function calling jbd2mightwaitforcommit(), potentially causing a deadlock if the EXT4IOCMIGRATE call races with a write(2) system call. This problem only arises when CONFIGPROVELOCKING is enabled. In this case, the jbd2mightwaitforcommit macro locks jbd2handle in the jbd2journalstop function while idatasem is locked. This triggers lockdep because the jbd2journalstart function might also lock the same jbd2handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)

In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfatloadbitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x66/0x90 registerlockclass+0x759/0x7d0 _lockacquire+0x85/0x2630 ? _findgetblock+0xb4/0x380 lockacquire+0xd1/0x2d0 ? _ext4journalgetwriteaccess+0xd5/0x160 _rawspinlock+0x33/0x40 ? _ext4journalgetwriteaccess+0xd5/0x160 _ext4journalgetwriteaccess+0xd5/0x160 ext4reserveinodewrite+0x61/0xb0 _ext4markinodedirty+0x79/0x270 ? ext4extreplaysetiblocks+0x2f8/0x450 ext4extreplaysetiblocks+0x330/0x450 ext4fcreplay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcuiswatching+0x11/0x40 doonepass+0x447/0xd00 jbd2journalrecover+0x139/0x1b0 jbd2journalload+0x96/0x390 ext4loadandinitjournal+0x253/0xd40 ext4fillsuper+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->sbdevwblock in function ext4checkbdevwriteerror(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in _ext4fillsuper() fixes this splat.(CVE-2024-50014)

In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rqqoswait vs. rqqoswakefunction race We're seeing crashes from rqqoswakefunction that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:rawspinlockirqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> trytowakeup+0x5a/0x6a0 rqqoswakefunction+0x71/0x80 _wakeupcommon+0x75/0xa0 _wakeup+0x36/0x60 scaleup.part.0+0x50/0x110 wbtimerfn+0x227/0x450 ... So rqqoswakefunction() calls wakeupprocess(data->task), which calls trytowakeup(), which faults in rawspinlockirqsave(&p->pilock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rqqoswait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wakeupprocess(), leading to the crash. What's happening is that in between rqqoswakefunction() deleting the waitqueue entry and calling wakeupprocess(), rqqoswait() is finding that it already got a token and returning. The race looks like this: rqqoswait() rqqoswakefunction() ============================================================== preparetowaitexclusive() data->gottoken = true; listdelinit(&curr->entry); if (data.gottoken) break; finishwait(&rqw->wait, &data.wq); ^- returns immediately because listemptycareful(&wqentry->entry) is true ... return, go do something else ... wakeupprocess(data->task) (NO LONGER VALID!)-^ Normally, finishwait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rqqoswakefunction() is accessing the waitqueue entry AFTER deleting it. Note that autoremovewakefunction() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use listdelinitcareful() to match the listemptycareful() in finishwait().(CVE-2024-50082)

In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases madagentpriv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el94.x8664 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ibmad1 timeoutsends [ibcore] RIP: 0010:dosoftirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? _irqexitrcu+0xa1/0xc0 ? watchdogtimerfn+0x1b2/0x210 ? _pfxwatchdogtimerfn+0x10/0x10 ? _hrtimerrunqueues+0x127/0x2c0 ? hrtimerinterrupt+0xfc/0x210 ? _sysvecapictimerinterrupt+0x5c/0x110 ? sysvecapictimerinterrupt+0x37/0x90 ? asmsysvecapictimerinterrupt+0x16/0x20 ? _dosoftirq+0x78/0x2ac ? _dosoftirq+0x60/0x2ac _irqexitrcu+0xa1/0xc0 sysveccallfunctionsingle+0x72/0x90 </IRQ> <TASK> asmsysveccallfunctionsingle+0x16/0x20 RIP: 0010:rawspinunlockirq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cmprocesssenderror+0x122/0x1d0 [ibcm] timeoutsends+0x1dd/0x270 [ibcore] processonework+0x1e2/0x3b0 ? _pfxworkerthread+0x10/0x10 workerthread+0x50/0x3a0 ? _pfxworkerthread+0x10/0x10 kthread+0xdd/0x100 ? _pfxkthread+0x10/0x10 retfrom_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)

In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stacktop() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stacktop(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stacktop+0x58/0xa8 [<90000000002956cc>] archpickmmaplayout+0x164/0x220 [<90000000003c284c>] kunitvmmmapinit+0x108/0x12c [<90000000003c1fbc>] _kunitaddresource+0x38/0x8c [<90000000003c2704>] kunitvmmmap+0x88/0xc8 [<9000000000410b14>] usercopytestinit+0xbc/0x25c [<90000000003c1db4>] kunittryruncase+0x5c/0x184 [<90000000003c3d54>] kunitgenericrunthreadfnadapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] retfromkernelthread+0xc/0xa4(CVE-2024-50133)

In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AFINET Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)

In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timerpending() in reqskqueueunlink(). Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler(). """ We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window. Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timerpending() by passing the caller context to _inetcskreqskqueuedrop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb(CVE-2024-50154)