OESA-2024-2536

The Linux Kernel, the operating system core itself.

Security Fix(es):

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: 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: posix-clock: posix-clock: Fix unbalanced locking in pcclocksettime() If getclockdesc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64validstrict() before getclockdesc() to fix it, because the "ts" is not changed after that. pabeni@redhat.com: fixed commit message typo

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: security/keys: fix slab-out-of-bounds in keytaskpermission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in _kuidval include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uideq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in keytaskpermission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: _dumpstack lib/dumpstack.c:82 [inline] dumpstack+0x107/0x167 lib/dumpstack.c:123 printaddressdescription.constprop.0+0x19/0x170 mm/kasan/report.c:400 _kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 _kuidval include/linux/uidgid.h:36 [inline] uideq include/linux/uidgid.h:63 [inline] keytaskpermission+0x394/0x410 security/keys/permission.c:54 searchnestedkeyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the searchnestedkeyrings function, when it iterates through the slots in a node(below tag ascendtonode), if the slot pointer is meta and node->backpointer != NULL(it means a root), it will proceed to descendtonode. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyringptriskeyring function. However, KEYRINGPTRSUBTYPE is 0x2UL, the same as ASSOCARRAYPTRSUBTYPEMASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descendtonode if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.

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)