OESA-2024-2522

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked

When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting VNMIPENDING, and lets the CPU do the rest (hardware automatically sets VNMIBLOCKING when an NMI is injected).

However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly).

Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small).

That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a really good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support.(CVE-2024-39483)

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

serial: sc16is7xx: fix invalid FIFO access with special register set

When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading.

Call graph example: sc16is7xxstartup(): entry sc16is7xxmsproc(): entry sc16is7xxsettermios(): entry sc16is7xxsetbaud(): DLH/DLL = $009C --> access special register set sc16is7xxportirq() entry --> IIR is 0x0C sc16is7xxhandlerx() entry sc16is7xxfiforead(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCRCONFMODEA) sc16is7xxsetbaud(): exit --> Restore access to general register set

Fix the problem by claiming the efr_lock mutex when accessing the Special register set.(CVE-2024-44950)

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

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.

The dasdeseneeds_format function checks for error codes that signal the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)

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

drm/amd/display: Add missing NULL pointer check within dpcdextendaddress_range

[Why & How] ASSERT if return NULL from kcalloc.(CVE-2024-46808)

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

drm/amd/display: Check link_index before accessing dc->links[]

[WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index.

This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)

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

wifi: iwlwifi: mvm: use IWLFWCHECK for link ID check

The lookup function iwlmvmrcufwlinkidtolinkconf() is normally called with input from the firmware, so it should use IWLFWCHECK() instead of WARN_ON().(CVE-2024-46825)

In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sdreadblockcharacteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sdreadblockcharacteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.(CVE-2024-47682)

In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ --------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | --------------\ -------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfqinsertrequest -> by Process 1 bfqq = bfqinitrq(rq) bfqq = bfqgetbfqqhandlesplit bfqq = bictobfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqqprocessrefs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 _bfqinsertrequest newbfqq = bfqsetupcooperator -> get bfqq3 from bfqq2->newbfqq bfqqrequestfreed(bfqq) newbfqq->ref++ rq->elv.priv[1] = newbfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqrequeuework Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:364 [inline] printreport+0x10d/0x610 mm/kasan/report.c:475 kasanreport+0x8e/0xc0 mm/kasan/report.c:588 bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfqgetbfqqhandlesplit+0x169/0x5d0 block/bfq-iosched.c:6757 bfqinitrq block/bfq-iosched.c:6876 [inline] bfqinsertrequest block/bfq-iosched.c:6254 [inline] bfqinsertrequests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blkmqinsertrequest+0x290/0x8d0 block/blk-mq.c:2593 blkmqrequeuework+0x6bc/0xa70 block/blk-mq.c:1502 processonework kernel/workqueue.c:2627 [inline] processscheduledworks+0x432/0x13f0 kernel/workqueue.c:2700 workerthread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:305 </TASK> Allocated by task 20776: kasansavestack+0x20/0x40 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 _kasanslaballoc+0x87/0x90 mm/kasan/common.c:328 kasanslaballoc include/linux/kasan.h:188 [inline] slabpostallochook mm/slab.h:763 [inline] slaballocnode mm/slub.c:3458 [inline] kmemcacheallocnode+0x1a4/0x6f0 mm/slub.c:3503 ioccreateicq block/blk-ioc.c:370 [inline] ---truncated---(CVE-2024-47706)

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct txant. Without this patch, the txant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996mcuadd_sta+0x12e0/0x16e0 mt7996e

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915bandconfig() sets bandidx = 1 on the main phy for mt7986 with MT7975ONEADIE or MT7976ONEADIE. Commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status") introduced a dereference of the phys array indirectly indexed by bandidx via wcid->phyidx in mt76wcidcleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76connaclib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76wcidcleanup+0x84/0x22c [mt76] lr : mt76wcidcleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76wcidcleanup+0x84/0x22c [mt76] mt76staremove+0x70/0xbc [mt76] mt76stastate+0x8c/0x1a4 [mt76] mt7915eepromgetpowerdelta+0x11e4/0x23a0 [mt7915e] drvstastate+0x144/0x274 [mac80211] stainfomovestate+0x1cc/0x2a4 [mac80211] stasetsinfo+0xaf8/0xc24 [mac80211] stainfodestroyaddrbss+0x4c/0x6c [mac80211] ieee80211colorchangefinish+0x1c08/0x1e70 [mac80211] cfg80211checkstationchange+0x1360/0x4710 [cfg80211] genlfamilyrcvmsgdoit+0xb4/0x110 genlrcvmsg+0xd0/0x1bc netlinkrcvskb+0x58/0x120 genlrcv+0x34/0x50 netlinkunicast+0x1f0/0x2ec netlinksendmsg+0x198/0x3d0 _syssendmsg+0x1b0/0x210 _syssendmsg+0x80/0xf0 _syssendmsg+0x44/0xa0 _arm64syssendmsg+0x20/0x30 invokesyscall.constprop.0+0x4c/0xe0 doel0svc+0x40/0xd0 el0svc+0x14/0x4c el0t64synchandler+0x100/0x110 el0t64sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76devphy() which will map band_idx to the correct phy for all hardware combinations.(CVE-2024-47715)

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtwwaitfirmwarecompletion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtwusbintfinit()' has failed in 'rtwusbprobe()', 'rtwusbdisconnect()' may issue 'ieee80211freehw()' when one of 'rtwloadfirmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.(CVE-2024-47718)

In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bondxdpgetxmitslave() syzbot reported a WARNING in bondxdpgetxmitslave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpfmasterredirectenabledkey. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDPTX. This triggers WARNONONCE() from the xdpmasterredirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARNONONCE() and add ratelimit to the netdeverr(). [1] Steps to reproduce: # Needs txxdp with return XDPTX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BONDMODEALB, unsupported by XDP ip l add bond1 type bond # BONDMODEROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpfmasterredirectenabledkey ip l set dev bond1 xdpdrv object txxdp.o section xdptx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARNONONCE() from the xdpmasterredirect() ip l set veth3 xdpgeneric object txxdp.o section xdptx(CVE-2024-47734)

In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODEWRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inodeownerorcapable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inodeownerorcapable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FSIOCSTARTATOMICREPLACE + F2FSIOCCOMMITATOMICWRITE can truncate an inode to size 0 - F2FSIOCSTARTATOMICWRITE + F2FSIOCABORTATOMICWRITE can revert changes another process concurrently made to a file Fix it by requiring FMODEWRITE for these operations, just like for F2FSIOCMOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.(CVE-2024-47740)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsvqp on HIP08 Currently rsvqp is freed before ibunregisterdevice() is called on HIP08. During the time interval, users can still dereg MR and rsvqp will be used in this process, leading to a UAF. Move the release of rsvqp after calling ibunregisterdevice() to fix it.(CVE-2024-47750)

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdech264reqmultiif.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47754)

In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpmdevtransmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.(CVE-2024-49851)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARGPTRTO{LONG,INT} as arguments. In checkfuncarg() when the argument is as mentioned, the meta->rawmode is never set. Later, checkhelpermemaccess(), under the case of PTRTOMAPVALUE as register base type, it assumes BPFREAD for the subsequent call to checkmapaccesstype() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARGPTRTO{LONG,INT} | MEMUNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARGPTRTO{LONG,INT} is a special case of ARGPTRTOFIXEDSIZEMEM just with additional alignment requirement. So it is better to just get rid of the ARGPTRTO{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEMALIGNED to additionally ensure alignment given these helpers write directly into the args via <ptr> = val. The .argsize has been initialized reflecting the actual sizeof(*<ptr>). MEMALIGNED can only be used in combination with MEMFIXEDSIZE annotated argument types, since in !MEMFIXEDSIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val.(CVE-2024-49861)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.(CVE-2024-49890)

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfcsliflushiorings(), lpfcdevlosstmocallbk(), or lpfcaborthandler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.(CVE-2024-49891)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clkmgr [WHY & HOW] dc->clkmgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.applyidlepoweroptimizations", which dereferences null "dc->clkmgr". (The function pointer resolves to "dcn35applyidlepoweroptimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwlmvmtxskbsta() and iwlmvmtxmpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwlmvmstafrommac80211, which is dereferencing the ieee80211sta pointer. If sta is NULL, iwlmvmstafrommac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmdcfgpkts") makes tx() calling devput() instead of doing in aoecmdcfgpkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmdatarw(), resend(), probe() and aoecmdcfgrsp(). Those functions also use aoenetxmit() to push packet to tx queue. So they should also use devhold() to increase the refcnt of skb->dev. On the other hand, moving devput() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding devhold() are not called in revalidate(), aoecmdatarw(), resend(), probe(), and aoecmdcfg_rsp(). This patch fixed this issue.(CVE-2024-49982)

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)

In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy pathnoexec check Both imode and noexec checks wrapped in WARNON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move SISREG() check earlier") 0fd338b2d2cd ("exec: move pathnoexec() check earlier") Instead of being removed said checks are WARNON'ed instead, which has some debug value. However, the spurious pathnoexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant pathnoexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. brauner: keep redundant path_noexec() check

In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.(CVE-2024-50023)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcommskstatechange rfcommskstatechange attempts to use socklock so it must never be called with it locked but rfcommsockioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sklock-AFBLUETOOTH-BTPROTORFCOMM){+.+.}-{0:0}, at: locksock include/net/sock.h:1671 [inline] ffff88807c396258 (sklock-AFBLUETOOTH-BTPROTORFCOMM){+.+.}-{0:0}, at: rfcommskstatechange+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: _rfcommdlcclose+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491(CVE-2024-50044)

In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbconputcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8t type; struct tioclselection ts; }; int main() { struct fbcon2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUTCON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.selmode = 0; int fd1 = open("/dev/tty1", ORDWR, 0); ioctl(fd1, TIOCLINUX, &param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUTCON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, &param), the subsequent ioctl(fd, FBIOPUTCON2FBMAP, &con2fb) causes the kernel to follow a different execution path: setcon2fbmap -> con2fbinitdisplay -> fbconsetdisp -> redrawscreen -> hidecursor -> clearselection -> highlight -> invertscreen -> doupdateregion -> fbconputcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call setblittingtype() within setcon2fbmap() to properly initialize ops->putcs.(CVE-2024-50048)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call isoexit() on module unload If isoinit() has been called, isoexit() must be called on module unload. Without that, the struct proto that isoinit() registered with protoregister() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIGLISTHARDENED and CONFIGBUGONDATACORRUPTION enabled, loading the module again usually triggers this BUG(): listadd corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:listaddvalidorreport+0x61/0xa0 ... _listaddvalidorreport+0x61/0xa0 protoregister+0x299/0x320 hcisockinit+0x16/0xc0 [bluetooth] btinit+0x68/0xd0 [bluetooth] _pfxbtinit+0x10/0x10 [bluetooth] dooneinitcall+0x80/0x2f0 doinitmodule+0x8b/0x230 _dosysinitmodule+0x15f/0x190 dosyscall_64+0x68/0x110 ...(CVE-2024-50078)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add sessionlock when setting SMB2SESSION_EXPIRED and referece count to session struct not to free session while it is being used.(CVE-2024-50086)

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pciforeachdmaalias() for non-PCI devices Previously, the domaincontextclear() function incorrectly called pciforeachdmaalias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pciforeachdmaalias() for PCI devices. For non-PCI devices, domaincontextclear_one() is called directly.(CVE-2024-50101)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmubpsrenable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b)(CVE-2024-50108)

In the Linux kernel, the following vulnerability has been resolved: net: sched: use RCU read-side critical section in tapriodump() Fix possible use-after-free in 'tapriodump()' by adding RCU read-side critical section there. Never seen on x86 but found on a KASAN-enabled arm64 system when investigating https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa: [T15862] BUG: KASAN: slab-use-after-free in tapriodump+0xa0c/0xbb0 [T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862 [T15862] [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2 [T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024 [T15862] Call trace: [T15862] dumpbacktrace+0x20c/0x220 [T15862] showstack+0x2c/0x40 [T15862] dumpstacklvl+0xf8/0x174 [T15862] printreport+0x170/0x4d8 [T15862] kasanreport+0xb8/0x1d4 [T15862] asanreportload4noabort+0x20/0x2c [T15862] tapriodump+0xa0c/0xbb0 [T15862] tcfillqdisc+0x540/0x1020 [T15862] qdiscnotify.isra.0+0x330/0x3a0 [T15862] tcmodifyqdisc+0x7b8/0x1838 [T15862] rtnetlinkrcvmsg+0x3c8/0xc20 [T15862] netlinkrcvskb+0x1f8/0x3d4 [T15862] rtnetlinkrcv+0x28/0x40 [T15862] netlinkunicast+0x51c/0x790 [T15862] netlinksendmsg+0x79c/0xc20 [T15862] _socksendmsg+0xe0/0x1a0 [T15862] _syssendmsg+0x6c0/0x840 [T15862] syssendmsg+0x1ac/0x1f0 [T15862] _syssendmsg+0x110/0x1d0 [T15862] _arm64syssendmsg+0x74/0xb0 [T15862] invokesyscall+0x88/0x2e0 [T15862] el0svccommon.constprop.0+0xe4/0x2a0 [T15862] doel0svc+0x44/0x60 [T15862] el0svc+0x50/0x184 [T15862] el0t64synchandler+0x120/0x12c [T15862] el0t64sync+0x190/0x194 [T15862] [T15862] Allocated by task 15857: [T15862] kasansavestack+0x3c/0x70 [T15862] kasansavetrack+0x20/0x3c [T15862] kasansaveallocinfo+0x40/0x60 [T15862] _kasankmalloc+0xd4/0xe0 [T15862] _kmalloccachenoprof+0x194/0x334 [T15862] tapriochange+0x45c/0x2fe0 [T15862] tcmodifyqdisc+0x6a8/0x1838 [T15862] rtnetlinkrcvmsg+0x3c8/0xc20 [T15862] netlinkrcvskb+0x1f8/0x3d4 [T15862] rtnetlinkrcv+0x28/0x40 [T15862] netlinkunicast+0x51c/0x790 [T15862] netlinksendmsg+0x79c/0xc20 [T15862] _socksendmsg+0xe0/0x1a0 [T15862] _syssendmsg+0x6c0/0x840 [T15862] _syssendmsg+0x1ac/0x1f0 [T15862] _syssendmsg+0x110/0x1d0 [T15862] _arm64syssendmsg+0x74/0xb0 [T15862] invokesyscall+0x88/0x2e0 [T15862] el0svccommon.constprop.0+0xe4/0x2a0 [T15862] doel0svc+0x44/0x60 [T15862] el0svc+0x50/0x184 [T15862] el0t64synchandler+0x120/0x12c [T15862] el0t64sync+0x190/0x194 [T15862] [T15862] Freed by task 6192: [T15862] kasansavestack+0x3c/0x70 [T15862] kasansavetrack+0x20/0x3c [T15862] kasansavefreeinfo+0x4c/0x80 [T15862] poisonslabobject+0x110/0x160 [T15862] _kasanslabfree+0x3c/0x74 [T15862] kfree+0x134/0x3c0 [T15862] tapriofreeschedcb+0x18c/0x220 [T15862] rcucore+0x920/0x1b7c [T15862] rcucoresi+0x10/0x1c [T15862] handlesoftirqs+0x2e8/0xd64 [T15862] _do_softirq+0x14/0x20(CVE-2024-50126)

In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in tapriochange() In 'tapriochange()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advancesched()', and critical section protected by 'q->currententrylock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcureplacepointer()' over 'rcuassign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.(CVE-2024-50127)

In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwanrtnlpolicy The variable wwanrtnllinkops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnetpolicy"). ================================================================== BUG: KASAN: global-out-of-bounds in validatenla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in nlavalidateparse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x177/0x231 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x14f/0x750 mm/kasan/report.c:395 kasanreport+0x139/0x170 mm/kasan/report.c:495 validatenla lib/nlattr.c:388 [inline] _nlavalidateparse+0x19d7/0x29a0 lib/nlattr.c:603 _nlaparse+0x3c/0x50 lib/nlattr.c:700 nlaparsenesteddeprecated include/net/netlink.h:1269 [inline] _rtnlnewlink net/core/rtnetlink.c:3514 [inline] rtnlnewlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlinkrcvmsg+0x794/0xef0 net/core/rtnetlink.c:6122 netlinkrcvskb+0x1de/0x420 net/netlink/afnetlink.c:2508 netlinkunicastkernel net/netlink/afnetlink.c:1326 [inline] netlinkunicast+0x74b/0x8c0 net/netlink/afnetlink.c:1352 netlinksendmsg+0x882/0xb90 net/netlink/afnetlink.c:1874 socksendmsgnosec net/socket.c:716 [inline] _socksendmsg net/socket.c:728 [inline] _syssendmsg+0x5cc/0x8f0 net/socket.c:2499 _syssendmsg+0x21c/0x290 net/socket.c:2553 _syssendmsg net/socket.c:2582 [inline] _dosyssendmsg net/socket.c:2591 [inline] _sesyssendmsg+0x19e/0x270 net/socket.c:2589 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x45/0x90 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 </TASK> The buggy address belongs to the variable: wwanrtnlpolicy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of nla_parse_nested_deprecated, use correct size IFLA_WWAN_MAX here to fix this issue.(CVE-2024-50128)

In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: must hold reference on net namespace BUG: KASAN: slab-use-after-free in _nfunregisternethook+0x640/0x6b0 Read of size 8 at addr ffff8880106fe400 by task repro/72= bpfnflinkrelease+0xda/0x1e0 bpflinkfree+0x139/0x2d0 bpflinkrelease+0x68/0x80 _fput+0x414/0xb60 Eric says: It seems that bpf was able to defer the _nfunregisternethook() after exit()/close() time. Perhaps a netns reference is missing, because the netns has been dismantled/freed already. bpfnflink_attach() does : link->net = net; But I do not see a reference being taken on net. Add such a reference and release it after hook unreg. Note that I was unable to get syzbot reproducer to work, so I do not know if this resolves this splat.(CVE-2024-50130)

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvmedevdisable() nvmedevdisable() modifies the dev->onlinequeues field, therefore nvmepciupdatenrqueues() should avoid racing against it, otherwise we could end up passing invalid values to blkmqupdatenrhwqueues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pciirqgetaffinity+0x187/0x210 Workqueue: nvme-reset-wq nvmeresetwork [nvme] RIP: 0010:pciirqgetaffinity+0x187/0x210 Call Trace: <TASK> ? blkmqpcimapqueues+0x87/0x3c0 ? pciirqgetaffinity+0x187/0x210 blkmqpcimapqueues+0x87/0x3c0 nvmepcimapqueues+0x189/0x460 [nvme] blkmqupdatenrhwqueues+0x2a/0x40 nvmeresetwork+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdownlock mutex before using dev->onlinequeues. Give up if nvmedev_disable() is running or if it has been executed already.(CVE-2024-50135)

In the Linux kernel, the following vulnerability has been resolved: reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC data->asserted will be NULL on JH7110 SoC since commit 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add the judgment condition to avoid errors when calling resetcontrolstatus on JH7110 SoC.(CVE-2024-50137)

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix shift-out-of-bounds bug Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sysregs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dumpbacktrace+0xa0/0x128 showstack+0x20/0x38 dumpstacklvl+0x74/0x90 dumpstack+0x18/0x28 _ubsanhandleshiftoutofbounds+0xf8/0x1e0 resetclidr+0x10c/0x1c8 kvmresetsysregs+0x50/0x1c8 kvmresetvcpu+0xec/0x2b0 _kvmvcpusettarget+0x84/0x158 kvmvcpusettarget+0x138/0x168 kvmarchvcpuioctlvcpuinit+0x40/0x2b0 kvmarchvcpuioctl+0x28c/0x4b8 kvmvcpuioctl+0x4bc/0x7a8 _arm64sysioctl+0xb4/0x100 invokesyscall+0x70/0x100 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x3c/0x158 el0t64synchandler+0x120/0x130 el0t64_sync+0x194/0x198(CVE-2024-50139)

In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIGDEBUGKOBJECTRELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobjectrelease, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typecaltmoderelease+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobjectdelayedcleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dumpstacklvl+0x5b/0x7c [ 46.617112] ? typecaltmoderelease+0x38/0x129 [ 46.617470] printreport+0x14c/0x49e [ 46.617769] ? rcureadunlocksched+0x56/0x69 [ 46.618117] ? _virtaddrvalid+0x19a/0x1ab [ 46.618456] ? kmemcachedebugflags+0xc/0x1d [ 46.618807] ? typecaltmoderelease+0x38/0x129 [ 46.619161] kasanreport+0x8d/0xb4 [ 46.619447] ? typecaltmoderelease+0x38/0x129 [ 46.619809] ? processscheduledworks+0x3cb/0x85f [ 46.620185] typecaltmoderelease+0x38/0x129 [ 46.620537] ? processscheduledworks+0x3cb/0x85f [ 46.620907] devicerelease+0xaf/0xf2 [ 46.621206] kobjectdelayedcleanup+0x13b/0x17a [ 46.621584] processscheduledworks+0x4f6/0x85f [ 46.621955] ? _pfxprocessscheduledworks+0x10/0x10 [ 46.622353] ? hlockclass+0x31/0x9a [ 46.622647] ? lockacquired+0x361/0x3c3 [ 46.622956] ? movelinkedworks+0x46/0x7d [ 46.623277] workerthread+0x1ce/0x291 [ 46.623582] ? _kthreadparkme+0xc8/0xdf [ 46.623900] ? _pfxworkerthread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? _pfxkthread+0x10/0x10 [ 46.625015] retfromfork+0x20/0x40 [ 46.625268] ? _pfxkthread+0x10/0x10 [ 46.625532] retfromforkasm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasansavestack+0x24/0x44 [ 46.626555] kasansavetrack+0x14/0x2d [ 46.626811] _kasankmalloc+0x3f/0x4d [ 46.627049] _kmallocnoprof+0x1bf/0x1f0 [ 46.627362] typecregisterport+0x23/0x491 [ 46.627698] crostypecprobe+0x634/0xbb6 [ 46.628026] platformprobe+0x47/0x8c [ 46.628311] reallyprobe+0x20a/0x47d [ 46.628605] devicedriverattach+0x39/0x72 [ 46.628940] bindstore+0x87/0xd7 [ 46.629213] kernfsfopwriteiter+0x1aa/0x218 [ 46.629574] vfswrite+0x1d6/0x29b [ 46.629856] ksyswrite+0xcd/0x13b [ 46.630128] dosyscall64+0xd4/0x139 [ 46.630420] entrySYSCALL64afterhwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasansavestack+0x24/0x44 [ 46.631493] kasansavetrack+0x14/0x2d [ 46.631799] kasansavefreeinfo+0x3f/0x4d [ 46.632144] _kasanslab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)

In the Linux kernel, the following vulnerability has been resolved: netdevsim: use condresched() in nsimdevtrapreportwork() I am still seeing many syzbot reports hinting that syzbot might fool nsimdevtrapreportwork() with hundreds of ports [1] Lets use condresched(), and systemunboundwq instead of implicit systemwq. [1] INFO: task syz-executor:20633 blocked for more than 143 seconds. Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006 ... NMI backtrace for cpu 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events nsimdevtrapreportwork RIP: 0010:_sanitizercovtracepc+0x0/0x70 kernel/kcov.c:210 Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> _localbhenableip+0x1bb/0x200 kernel/softirq.c:382 spinunlockbh include/linux/spinlock.h:396 [inline] nsimdevtrapreport drivers/net/netdevsim/dev.c:820 [inline] nsimdevtrapreportwork+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>(CVE-2024-50155)

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxtre: Fix out of bound check Driver exports pacing stats only on GenP5 and P7 adapters. But while parsing the pacing stats, driver has a check for "rdev->dbrpacing". This caused a trace when KASAN is enabled. BUG: KASAN: slab-out-of-bounds in bnxtregethwstats+0x2b6a/0x2e00 [bnxt_re] Write of size 8 at addr ffff8885942a6340 by task modprobe/4809(CVE-2024-50158)

In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpfredirect flags don't overlap The bpfredirectinfo is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPFFBROADCAST == BPFFNEXTHOP). This means that if skb bpfredirectneigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpfredirectinfo struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpfredirectinfo, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPFFREDIRECTINTERNAL to not overlap with the flags used for XDP. It also adds a BUILDBUGON() check to make sure the overlap is not re-introduced by mistake.(CVE-2024-50163)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEMUNINIT's meaning Lonial reported an issue in the BPF verifier where checkmemsizereg() has the following code: if (!tnumisconst(reg->varoff)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEMUNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARGPTRTORAWSTACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEMUNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEMUNINIT back to its original meaning, and having MEMWRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: checkargpairok() ensures that for ARGCONSTSIZE{,ORZERO} we can access fn->argtype[arg - 1] since it must contain a preceding ARGPTRTOMEM. For checkmemreg() the meta argument can be removed altogether since we do check both BPFREAD and BPFWRITE. Same for the equivalent checkkfuncmemsizereg().(CVE-2024-50164)

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in vc4_perfmon_close_file(), the active performance monitor's pointer (vc4->active_perfmon) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in vc4->active_perfmon. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50187)

In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmodesetbit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.(CVE-2024-50188)

In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts. for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, &reg); if (!reg) continue; chained_irq_enter(parent_chip, desc); However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt. Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chained_irq_enter drivers/pinctrl(CVE-2024-50196)

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possibleclones Include the encoder itself in its possibleclones bitmask. In the past nothing validated that drivers were populating possibleclones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possibleclones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possibleclones: [ENCODER:46:TV-46] possibleclones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drmmodeconfig.c:615 drmmodeconfig_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)

In the Linux kernel, the following vulnerability has been resolved: udf: refactor inodebmap() to handle error Refactor inodebmap() to handle error since udfnextaext() can return error now. On situations like ftruncate, udfextendfile() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions.(CVE-2024-50211)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2truncateinline maybe overflow Syzbot reported a kernel BUG in ocfs2truncateinline. There are two reasons for this: first, the parameter value passed is greater than ocfs2maxinlinedatawithxattr, second, the start and end parameters of ocfs2truncateinline are "unsigned int". So, we need to add a sanity check for bytestart and bytelen right before ocfs2truncateinline() in ocfs2removeinoderange(), if they are greater than ocfs2maxinlinedatawith_xattr return -EINVAL.(CVE-2024-50218)

In the Linux kernel, the following vulnerability has been resolved: ioviter: fix copypagefromiteratomic() if KMAPLOCALFORCEMAP generic/077 on x8632 CONFIGDEBUGKMAPLOCALFORCEMAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmaplocalindexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copypagefromiteratomic+0xa6/0x5ec genericperformwrite+0xf6/0x1b4 shmemfilewriteiter+0x54/0x67 Fix copypagefromiteratomic() by limiting it in that case (include/linux/skbuff.h skbfragmustloop() does similar). But going forward, perhaps CONFIGDEBUGKMAPLOCALFORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?(CVE-2024-50222)

In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxltest was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxltest crashing with a use-after-free bug with the following signature: cxlportattachregion: cxl region3: cxlhostbridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxlswitchuport.0 nreps: 1 nrtargets: 1 cxlportattachregion: cxl region3: cxlhostbridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxlswitchuport.0 nreps: 2 nrtargets: 1 cxlportsetuptargets: cxl region3: cxlswitchuport.0:port6 target[0] = cxlswitchdport.0 for mem0:decoder7.0 @ 0 1) cxlportsetuptargets: cxl region3: cxlswitchuport.0:port6 target[1] = cxlswitchdport.4 for mem4:decoder14.0 @ 1 [..] cxldunregister: cxl decoder14.0: cxlregiondecodereset: cxlregion region3: mockdecoderreset: cxlport port3: decoder3.0 reset 2) mockdecoderreset: cxlport port3: decoder3.0: out of order reset, expected decoder3.1 cxlendpointdecoderrelease: cxl decoder14.0: [..] cxldunregister: cxl decoder7.0: 3) cxlregiondecodereset: cxlregion region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:tocxlport+0x8/0x60 [cxlcore] [..] Call Trace: <TASK> cxlregiondecodereset+0x69/0x190 [cxlcore] cxlregiondetach+0xe8/0x210 [cxlcore] cxldecoderkillregion+0x27/0x40 [cxlcore] cxldunregister+0x5d/0x60 [cxlcore] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the "out of order reset case" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxlregiondecodereset() always succeed, cxlregioninvalidatememregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new deviceforeachchildreversefrom() is added to cleanup port->commitend after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commitend only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.(CVE-2024-50226)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem(). This is not a problem for symlinks read from the backing device, because the _GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held: Fix this issue by dropping the _GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and _nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqmconfig pointer on free When we free wdev->cqmconfig when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.(CVE-2024-50235)

In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsimnexthopbucketactivitywrite() This was found by a static analyzer. We should not forget the trailing zero after copyfromuser() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.(CVE-2024-50259)

In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadatadst, which is used to store the SCI value for macsec offload, is already freed by metadatadstfree() in macsecfreenetdev(), while driver still use it for sending the packet. To fix this issue, dstrelease() is used instead to release metadatadst. So it is not freed instantly in macsecfreenetdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5exmit+0x1e8f/0x4190 [mlx5core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mldifcwork Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xc1/0x600 kasanreport+0xab/0xe0 mlx5exmit+0x1e8f/0x4190 [mlx5core] devhardstartxmit+0x120/0x530 schdirectxmit+0x149/0x11e0 qdiscrun+0x3ad/0x1730 _devqueuexmit+0x1196/0x2ed0 vlandevhardstartxmit+0x32e/0x510 [8021q] devhardstartxmit+0x120/0x530 _devqueuexmit+0x14a7/0x2ed0 macsecstartxmit+0x13e9/0x2340 devhardstartxmit+0x120/0x530 _devqueuexmit+0x14a7/0x2ed0 ip6finishoutput2+0x923/0x1a70 ip6finishoutput+0x2d7/0x970 ip6output+0x1ce/0x3a0 NFHOOK.constprop.0+0x15f/0x190 mldsendpack+0x59a/0xbd0 mldifcwork+0x48a/0xa80 processonework+0x5aa/0xe50 workerthread+0x79c/0x1290 kthread+0x28f/0x350 retfromfork+0x2d/0x70 retfromforkasm+0x11/0x20 </TASK> Allocated by task 3922: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 _kasankmalloc+0x77/0x90 _kmallocnoprof+0x188/0x400 metadatadstalloc+0x1f/0x4e0 macsecnewlink+0x914/0x1410 _rtnlnewlink+0xe08/0x15b0 rtnlnewlink+0x5f/0x90 rtnetlinkrcvmsg+0x667/0xa80 netlinkrcvskb+0x12c/0x360 netlinkunicast+0x551/0x770 netlinksendmsg+0x72d/0xbd0 _socksendmsg+0xc5/0x190 _syssendmsg+0x52e/0x6a0 syssendmsg+0xeb/0x170 _syssendmsg+0xb5/0x140 dosyscall64+0x4c/0x100 entrySYSCALL64afterhwframe+0x4b/0x53 Freed by task 4011: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x50 poisonslabobject+0x10c/0x190 _kasanslabfree+0x11/0x30 kfree+0xe0/0x290 macsecfreenetdev+0x3f/0x140 netdevruntodo+0x450/0xc70 rtnetlinkrcvmsg+0x66f/0xa80 netlinkrcvskb+0x12c/0x360 netlinkunicast+0x551/0x770 netlinksendmsg+0x72d/0xbd0 _socksendmsg+0xc5/0x190 _syssendmsg+0x52e/0x6a0 _syssendmsg+0xeb/0x170 _syssendmsg+0xb5/0x140 dosyscall64+0x4c/0x100 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2024-50261)

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: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cachecreate to allocate new in-core data structures that fit the new size, and the check in cachepreresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in isdirtycallback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpudebugfsgprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)(CVE-2024-50282)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbdworkcache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.(CVE-2024-50285)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbdsmb2sessioncreate There is a race condition between ksmbdsmb2sessioncreate and ksmbdexpiresession. This patch add missing sessionstablelock while adding/deleting session from global session table.(CVE-2024-50286)

In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.(CVE-2024-50300)

In the Linux kernel, the following vulnerability has been resolved: ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelinitflow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdevmasterupperifindexbyindex() which will acquire the RCU read lock before calling l3mdevmasterupperifindexbyindexrcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 devgetbyindexrcu+0x1d3/0x210 l3mdevmasterupperifindexbyindexrcu+0x2b/0xf0 iptunnelbinddev+0x72f/0xa00 iptunnelnewlink+0x368/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 _syssendmsg+0x8f9/0xc20 _syssendmsg+0x197/0x1e0 _syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-53042)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwlmvmsendrecoverycmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwlmvmsendcmdstatus(), which handles both size validation and frees the buffer.(CVE-2024-53059)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpievaluateobject() may return AENOTFOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AENOTFOUND. This fixes 1 FORWARDNULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARDNULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)(CVE-2024-53060)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pendingasynccopies on error The error flow in nfsd4copy() calls cleanupasynccopy(), which already decrements nn->pendingasync_copies.(CVE-2024-53073)

In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afswakeupasynccall() can incur lock recursion. The problem is that it is called from AFRXRPC whilst holding the ->notifylock, but it tries to take a ref on the afscall struct in order to pass it to a work queue - but if the afscall is already queued, we then have an extraneous ref that must be put... calling afsputcall() may call back down into AFRXRPC through rxrpckernelshutdowncall(), however, which might try taking the ->notifylock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .ownercpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dumpstacklvl+0x47/0x70 dorawspinlock+0x3c/0x90 rxrpckernelshutdowncall+0x83/0xb0 afsputcall+0xd7/0x180 rxrpcnotifysocket+0xa0/0x190 rxrpcinputsplitjumbo+0x198/0x1d0 rxrpcinputdata+0x14b/0x1e0 ? rxrpcinputcallpacket+0xc2/0x1f0 rxrpcinputcallevent+0xad/0x6b0 rxrpcinputpacketonconn+0x1e1/0x210 rxrpcinputpacket+0x3f2/0x4d0 rxrpciothread+0x243/0x410 ? _pfxrxrpciothread+0x10/0x10 kthread+0xcf/0xe0 ? _pfxkthread+0x10/0x10 retfromfork+0x24/0x40 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>(CVE-2024-53090)