OESA-2024-2534

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhciinvalidatecancelledtds() again from xhcihandlecmdsetdeq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhciwarn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhcidbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhcidbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me months of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use hdparm to mark an early sector (e.g. 1024) on a disk as bad, then cat /dev/sdX > /dev/null in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the cat in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211dostop() Since '_devqueuexmit()' should be called with interrupts enabled, the following backtrace: ieee80211dostop() ... spinlockirqsave(&local->queuestopreasonlock, flags) ... ieee80211freetxskb() ieee80211reportusedskb() ieee80211reportackskb() cfg80211mgmttxstatusext() nl80211frametxstatus() genlmsgmulticastnetns() genlmsgmulticastnetnsfiltered() nlmsgmulticastfiltered() netlinkbroadcastfiltered() doonebroadcast() netlinkbroadcastdeliver() _netlinksendskb() netlinkdelivertap() _netlinkdelivertapskb() devqueuexmit() _devqueuexmit() ; with IRQS disabled ... spinunlockirqrestore(&local->queuestopreasonlock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 _localbhenableip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211dostop()', where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)

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: vhost/scsi: null-ptr-dereference in vhostscsigetreq() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhostscsictlhandlevq(), vc.target is assigned with &v_req.tmf.lun[1] within a switch-case block and is then passed to vhostscsigetreq() which extracts vc->req and tpg. However, for a VIRTIO_SCSI_T_AN_* request, tpg is not required, so vc.target is set to NULL in this branch. Later, in vhostscsigetreq(), vc->target is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhostworker process is killed while holding vq->mutex and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhostscsigetreq+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: <TASK> ? showregs+0x86/0xa0 ? dieaddr+0x4b/0xd0 ? excgeneralprotection+0x163/0x260 ? asmexcgeneralprotection+0x27/0x30 ? vhostscsigetreq+0x165/0x3a0 vhostscsictlhandlevq+0x2a4/0xca0 ? _pfxvhostscsictlhandlevq+0x10/0x10 ? _switchto+0x721/0xeb0 ? _schedule+0xda5/0x5710 ? _kasancheckwrite+0x14/0x30 ? _rawspinlock+0x82/0xf0 vhostscsictlhandlekick+0x52/0x90 vhostrunworklist+0x134/0x1b0 vhosttaskfn+0x121/0x350 ... </TASK> ---[ end trace 0000000000000000 ]--- Let's add a check in vhostscsiget_req. whitespace fixes

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipectx->planestate check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20validateapplypipesplitflags [WHAT & HOW] "dcn20validateapplypipesplitflags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "porttransmitratekbps" to be set to a value of 0, which is then passed to the "divs64" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfdfreegttmem clear the correct pointer Pass pointer reference to amdgpubounref to clear the correct pointer, otherwise amdgpubo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asocqcomlpasscpuplatformprobe() A devmkzalloc() in asocqcomlpasscpuplatform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUGON check for the buffer delay flag in submitbh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)

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: drm/vboxvideo: Replace fake VLA at end of vbvamousepointershape with real VLA Replace the fake VLA at end of the vbvamousepointershape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 hgsmiupdatepointershape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmiupdatepointershape [vboxvideo] [ 13.320184] vboxcursoratomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)

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: 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: USB: serial: ioedgeport: fix use after free in debug printk The "devdbg(&urb->dev->dev, ..." which happens after usbfreeurb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue.(CVE-2024-50267)

In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemapread() If the caller supplies an iocb->kipos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts.(CVE-2024-50272)

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: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.(CVE-2024-50290)

In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32spdifrxremove In case of error when requesting ctrlchan DMA channel, ctrlchan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dmarequestslavechannel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dmareleasechannel+0x24/0x100 [ 5.103235] stm32spdifrxremove+0x24/0x60 [sndsocstm32spdifrx] [ 5.109494] stm32spdifrxprobe+0x320/0x4c4 [sndsocstm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)

In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.(CVE-2024-53104)

In the Linux kernel, the following vulnerability has been resolved: vpvdpa: fix idtable array not null terminated error Allocate one extra virtiodeviceid as null terminator, otherwise vdpamgmtdevget_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? _diebody+0x5f/0xb0 ? die+0x9e/0xc0 ? dotrap+0x15a/0x3a0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? doerrortrap+0x1dc/0x2c0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? _pfxdoerrortrap+0x10/0x10 ? handleinvalidop+0x34/0x40 ? ocfs2setnewbufferuptodate+0x145/0x160 ? excinvalidop+0x38/0x50 ? asmexcinvalidop+0x1a/0x20 ? ocfs2setnewbufferuptodate+0x2e/0x160 ? ocfs2setnewbufferuptodate+0x144/0x160 ? ocfs2setnewbufferuptodate+0x145/0x160 ocfs2groupadd+0x39f/0x15a0 ? _pfxocfs2groupadd+0x10/0x10 ? _pfxlockacquire+0x10/0x10 ? mntgetwriteaccess+0x68/0x2b0 ? _pfxlockrelease+0x10/0x10 ? rcureadlockanyheld+0xb7/0x160 ? _pfxrcureadlockanyheld+0x10/0x10 ? smacklog+0x123/0x540 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x226/0x2b0 ocfs2ioctl+0x65e/0x7d0 ? _pfxocfs2ioctl+0x10/0x10 ? smackfileioctl+0x29e/0x3a0 ? _pfxsmackfileioctl+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? _pfxlockdephardirqsonprepare+0x10/0x10 ? _pfxocfs2ioctl+0x10/0x10 _sesysioctl+0xfb/0x170 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK> When 'ioctl(OCFS2IOCGROUPADD, ...)' has failed for the particular inode in 'ocfs2verifygroupandinput()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2setnewbufferuptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2removefromcache()' on error path in 'ocfs2group_add()'.(CVE-2024-53112)

In the Linux kernel, the following vulnerability has been resolved: bpf: synclinkedregs() must preserve subregdef Range propagation must not affect subregdef marks, otherwise the following example is rewritten by verifier incorrectly when BPFFTESTRNDHI32 flag is set: 0: call bpfktimegetns call bpfktimegetns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subregdef is overridden at (3) by copyregisterstate(); - w1 is read at (5) but markinsnzext() does not mark (2) for zero extension, because w1 subregdef is not set; - because of BPFFTESTRNDHI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in blockdirtybuffer tracepoint When using the "block:blockdirtybuffer" tracepoint, markbufferdirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in markbufferdirty(), it references the devt member bh->bbdev->bddev regardless of whether the buffer head has a pointer to a blockdevice structure. In the current implementation, nilfsgrabbuffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by trytofreebuffers(), and new buffer heads are then attached by createemptybuffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->bbdev, and markbufferdirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfsgrabbuffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.(CVE-2024-53130)