OESA-2025-1034

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: sh: cpuinfo: Fix a warning for CONFIGCPUMASKOFFSTACK When CONFIGCPUMASKOFFSTACK and CONFIGDEBUGPERCPUMAPS are selected, cpumaxbitswarn() generates a runtime warning similar as below when showing /proc/cpuinfo. Fix this by using nrcpuids (the runtime limit) instead of NRCPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 showcpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] showstack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dumpstacklvl+0x60/0x88 [ 3.217625] [<900000000023d268>] _warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warnslowpathfmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] showcpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seqreaditer+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] newsyncread+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfsread+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksysread+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] dosyscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handlesyscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)

In the Linux kernel, the following vulnerability has been resolved: media: s5pcec: limit msg.len to CECMAXMSGSIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.(CVE-2022-49035)

In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcprtodeltaus() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcprearmrto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: errorcode(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? showregs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? _die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? nocontext+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6protocoldeliverrcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6sublistrcvfinish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? _badareanosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? badareanosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? douseraddrfault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6listrcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? _dopagefault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? dopagefault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? pagefault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcpsendlossprobe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcpwritetimerhandler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcpwritetimer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcpwritetimerhandler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] calltimerfn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] _runtimers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibratecpukhz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? nativex2apicicrwrite+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapicnext_even ---truncated---(CVE-2024-47684)

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: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-50264)

In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-53103)

In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->skforwardalloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 _skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? _pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule _skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() _kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable _skmemreclaim skforwardallocadd() In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 _skmemschedule() | | +4096 = 4096 | _skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | _skmemreclaim() | | -4096 = 4096 | _skmemreclaim() | -8192 = -4096 != 0 The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6do_rcv().(CVE-2024-53124)

In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.(CVE-2024-53140)

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmapipuadt When tb[IPSETATTRIPTO] is not present but tb[IPSETATTRCIDR] exists, the values of ip and ipto are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decodecb_compound4res() does not have to perform arithmetic on the unsafe length value.(CVE-2024-53146)

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: geni-se: fix array underflow in geniseclktblget() This loop is supposed to break if the frequency returned from clkroundrate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clkperftbl[] array.(CVE-2024-53158)

In the Linux kernel, the following vulnerability has been resolved: sh: intc: Fix use-after-free bug in registerintccontroller() In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let's only add it to the list after everything has succeeded.(CVE-2024-53165)

In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfsreleaseseqid() in nfs4opendatafree() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfswaitonsequence() is complete, then we must call nfsreleaseseqid() in nfs4openrelease() before the rpctask is freed.(CVE-2024-53173)

In the Linux kernel, the following vulnerability has been resolved: um: net: Do not use drvdata in release The drvdata is not available in release. Let's just use containerof() to get the umlnet instance. Otherwise, removing a network device will result in a crash: RIP: 0033:netdevicerelease+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mcworkproc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] devicerelease+0x70/0xba [<603a2bcd>] kobjectput+0xba/0xe7 [<60277265>] putdevice+0x19/0x1c [<60281266>] platformdeviceput+0x26/0x29 [<60281e5f>] platformdeviceunregister+0x2c/0x2e [<6002ec9c>] netremove+0x63/0x69 [<60031316>] ? mconsolereply+0x0/0x50 [<600310c8>] mconsoleremove+0x160/0x1cc [<60087d40>] ? _removehrtimer+0x38/0x74 [<60087ff8>] ? hrtimertrytocancel+0x8c/0x98 [<6006b3cf>] ? dlserverstop+0x3f/0x48 [<6006b390>] ? dlserverstop+0x0/0x48 [<600672e8>] ? dequeueentities+0x327/0x390 [<60038fa6>] ? umsetsignals+0x0/0x43 [<6003070c>] mcworkproc+0x77/0x91 [<60057664>] processscheduledworks+0x1b3/0x2dd [<60055f32>] ? assignwork+0x0/0x58 [<60057f0a>] workerthread+0x1e9/0x293 [<6005406f>] ? setpfworker+0x0/0x64 [<6005d65d>] ? archlocalirqsave+0x0/0x2d [<6005d748>] ? kthreadexit+0x0/0x3a [<60057d21>] ? workerthread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] newthread_handler+0x85/0xb6(CVE-2024-53183)

In the Linux kernel, the following vulnerability has been resolved: um: ubd: Do not use drvdata in release The drvdata is not available in release. Let's just use containerof() to get the ubd instance. Otherwise, removing a ubd device will result in a crash: RIP: 0033:blkmqfreetagset+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Kernel panic - not syncing: Segfault with no mm CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1 Workqueue: events mcworkproc Stack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0 Call Trace: [<6002c776>] ubddevicerelease+0x21/0x55 [<6002c755>] ? ubddevicerelease+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] devicerelease+0x70/0xba [<60381d6a>] kobjectput+0xb5/0xe2 [<6026027b>] putdevice+0x19/0x1c [<6026a036>] platformdeviceput+0x26/0x29 [<6026ac5a>] platformdeviceunregister+0x2c/0x2e [<6002c52e>] ubdremove+0xb8/0xd6 [<6002bb74>] ? mconsolereply+0x0/0x50 [<6002b926>] mconsoleremove+0x160/0x1cc [<6002bbbc>] ? mconsolereply+0x48/0x50 [<6003379c>] ? umsetsignals+0x3b/0x43 [<60061c55>] ? updateminvruntime+0x14/0x70 [<6006251f>] ? dequeuetaskfair+0x164/0x235 [<600620aa>] ? updatecfsgroup+0x0/0x40 [<603a0e77>] ? _schedule+0x0/0x3ed [<60033761>] ? umsetsignals+0x0/0x43 [<6002af6a>] mcworkproc+0x77/0x91 [<600520b4>] processscheduledworks+0x1af/0x2c3 [<6004ede3>] ? assignwork+0x0/0x58 [<600527a1>] workerthread+0x2f7/0x37a [<6004ee3b>] ? setpfworker+0x0/0x64 [<6005765d>] ? archlocalirqsave+0x0/0x2d [<60058e07>] ? kthreadexit+0x0/0x3a [<600524aa>] ? workerthread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] newthreadhandler+0x85/0xb6(CVE-2024-53184)

In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pcislot on bind and destroys it on unbind. The pcislot contains a pointer to the pcibus below the Downstream Port, but a reference on that pcibus is never acquired. The pcibus is destroyed before the pcislot, so a use-after-free ensues when pcislotrelease() accesses slot->bus. In principle this should not happen because pcistopbusdevice() unbinds pciehp (and therefore destroys the pcislot) before the pcibus is destroyed by pciremovebusdevice(). However the stacktrace provided by Dennis shows that pciehp is unbound from pciremovebusdevice() instead of pcistopbusdevice(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pcistopbusdevice() and then actually removes the devices in pciremovebusdevice(). There is no precaution to prevent driver binding in-between pcistopbusdevice() and pciremovebusdevice(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pcibusadddevices(). pciehp is bound to the Downstream Port after pcistopbusdevice() has run, so it is unbound by pciremovebusdevice() instead of pcistopbusdevice(). Because the pcibus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pcistopbusdevice() has run. However it seems risky that pcislot points to pcibus without holding a reference. Solely relying on correct ordering of driver unbind versus pcibus destruction is certainly not defensive programming. If pcislot has a need to access data in pcibus, it ought to acquire a reference. Amend pcicreateslot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pcibus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pciedisablenotification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:devdriverstring+0x12/0x40 pcidestroyslot pciehpremove pcieportremoveservice devicereleasedriverinternal busremovedevice devicedel deviceunregister removeiter deviceforeachchild pcieportdrvremove pcideviceremove devicereleasedriverinternal busremovedevice devicedel pciremovebusdevice (recursive invocation) pciremovebusdevice pciehpunconfiguredevice pciehpdisableslot pciehphandlepresenceorlinkchange pciehp_ist(CVE-2024-53194)

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.(CVE-2024-53197)

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Properly hide first-in-list PCIe extended capability There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCIEXTCAPIDMAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfiopcicoredevice->pciconfigmap is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfioconfigdorw(). This leads to the following warning [1] and to an out-of-bounds access to ecapperms array. Fix it by checking capid in vfioconfigdorw(), and if it is greater than PCIEXTCAPIDMAX, use an alternative struct permbits for direct read only access instead of the ecapperms array. Note that this is safe since the above is the only case where capid can exceed PCIEXTCAPIDMAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfiopciconfig.c:1900 vfiopciconfigrw+0x395/0x430 [vfiopcicore] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? showregs+0x69/0x80 ? _warn+0x8d/0x140 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? reportbug+0x18f/0x1a0 ? handlebug+0x63/0xa0 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? vfiopciconfigrw+0x244/0x430 [vfiopcicore] vfiopcirw+0x101/0x1b0 [vfiopcicore] vfiopcicoreread+0x1d/0x30 [vfiopcicore] vfiodevicefopsread+0x27/0x40 [vfio] vfsread+0xbd/0x340 ? vfiodevicefopsunlioctl+0xbb/0x740 [vfio] ? _rseqhandlenotifyresume+0xa4/0x4b0 _x64syspread64+0x96/0xc0 x64syscall+0x1c3d/0x20d0 dosyscall64+0x4d/0x120 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-53214)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4processcbupdate() @ses is initialized to NULL. If _nfsd4findbackchannel() finds no available backchannel session, setupcallbackclient() will try to dereference @ses and segfault.(CVE-2024-53217)

In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6firechipabort(). But at this moment, the card object might be still in use (as we're calling sndcardfreewhenclosed()). For avoid potential UAFs, move the release of resources to the card's privatefree instead of the manual call of usb6firechip_destroy() at the USB disconnect callback.(CVE-2024-53239)

In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Use sndcardfreewhenclosed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses sndcardfree() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace sndcardfree() with sndcardfreewhenclosed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.(CVE-2024-56531)

In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Use sndcardfreewhenclosed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses sndcardfree() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace sndcardfree() with sndcardfreewhenclosed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. The loop of us122l->mmapcount check is dropped as well. The check is useless for the asynchronous operation with *when_closed().(CVE-2024-56532)

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexconfigscan() Replace one-element array with a flexible-array member in struct mwifiex_ie_types_wildcard_ssid_params to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcardssidtlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiexscannetworks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssidlen = userscanin->ssidlist[i].ssidlen; [...] memcpy(wildcardssidtlv->ssid, userscanin->ssidlist[i].ssid, ssidlen); There is a #define WILDCARDSSIDTLVMAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)

In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahashhmacinit function The ahashinit functions may return fails. The ahashhmacinit should not return ok when ahashinit returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error.(CVE-2024-56681)

In the Linux kernel, the following vulnerability has been resolved: media: wl128x: Fix atomicity violation in fmcsendcmd() Atomicity violation occurs when the fmcsendcmd() function is executed simultaneously with the modification of the fmdev->respskb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->respskb variable is assigned a null value. This results in an invalid fmdev->respskb variable passing the validity check. As seen in the later part of the function, skb = fmdev->respskb; when the invalid fmdev->respskb passes the check, a null pointer dereference error may occur at line 478, evthdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->respskb within the locked section of the function. This modification ensures that the value of fmdev->respskb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations.(CVE-2024-56700)

In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. Dominique: remove confusing variable reset to 0

In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fballocmem() When information such as info->screenbase is not ready, calling sh7760fbfreemem() does not release memory correctly. Call dmafree_coherent() instead.(CVE-2024-56746)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qediallocandinitsb() Hook "qediops->common->sbinit = qedsbinit" does not release the DMA memory sbvirt when it fails. Add dmafreecoherent() to free it. This is the same way as qedrallocmemsb() and qedeallocmem_sb().(CVE-2024-56747)