OESA-2025-1016

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

dmaengine: idxd: Let probe fail when workqueue cannot be enabled

The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling.

Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drvenablewq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove.

Some examples of problematic flows: (a)

idxddmaenginedrvprobe() -> drvenablewq() -> idxdwqrequestirq(): In above flow, if idxdwqrequestirq() fails then idxdwqunmapportal() is called on error exit path, but drvenablewq() returns 0 because idxdwqdisable() succeeds. The driver is thus loaded successfully.

idxddmaenginedrvremove()->drvdisablewq()->idxdwqunmapportal() Above flow on driver unload triggers the WARN in devmiounmap() because the device resource has already been removed during error path of drvenable_wq().

(b)

idxddmaenginedrvprobe() -> drvenablewq() -> idxdwqrequestirq(): In above flow, if idxdwqrequestirq() fails then idxdwqinitpercpuref() is never called to initialize the percpu counter, yet the driver loads successfully because drvenable_wq() returns 0.

idxddmaenginedrvremove()->idxdwqquiesce()->percpuref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010

Fix the drvenablewq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully.(CVE-2022-48868)

In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when btinit fails btinit() calls btledsinit() to register led, but if it fails later, btledscleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another ledtriggerregister() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> ledtriggerregister+0x10d/0x4f0 ledtriggerregistersimple+0x7d/0x100 btinit+0x39/0xf7 [bluetooth] dooneinitcall+0xd0/0x4e0(CVE-2022-48971)

In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tundetach() syzbot reported use-after-free in tundetach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifiercallchain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd1/0x138 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x15e/0x461 mm/kasan/report.c:395 kasanreport+0xbf/0x1f0 mm/kasan/report.c:495 notifiercallchain+0x1ee/0x200 kernel/notifier.c:75 callnetdevicenotifiersinfo+0x86/0x130 net/core/dev.c:1942 callnetdevicenotifiersextack net/core/dev.c:1983 [inline] callnetdevicenotifiers net/core/dev.c:1997 [inline] netdevwaitallrefsany net/core/dev.c:10237 [inline] netdevruntodo+0xbc6/0x1100 net/core/dev.c:10351 tundetach drivers/net/tun.c:704 [inline] tunchrclose+0xe4/0x190 drivers/net/tun.c:3467 _fput+0x27c/0xa90 fs/filetable.c:320 taskworkrun+0x16f/0x270 kernel/taskwork.c:179 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0xb3d/0x2a30 kernel/exit.c:820 dogroupexit+0xd4/0x2a0 kernel/exit.c:950 getsignal+0x21b1/0x2440 kernel/signal.c:2858 archdosignalorrestart+0x86/0x2300 arch/x86/kernel/signal.c:869 exittousermodeloop kernel/entry/common.c:168 [inline] exittousermodeprepare+0x15f/0x250 kernel/entry/common.c:203 _syscallexittousermodework kernel/entry/common.c:285 [inline] syscallexittousermode+0x1d/0x50 kernel/entry/common.c:296 dosyscall64+0x46/0xb0 arch/x86/entry/common.c:86 entrySYSCALL64afterhwframe+0x63/0xcd The cause of the issue is that sockput() from _tundetach() drops last reference count for struct net, and then notifiercallchain() from netdevstatechange() accesses that struct net. This patch fixes the issue by calling sockput() from tun_detach() after all necessary accesses for the struct net has done.(CVE-2022-49014)

In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-49015)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac8021: fix possible oob access in ieee80211getrateduration Fix possible out-of-bound access in ieee80211getrateduration routine as reported by the following UBSAN report: UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47 index 15 is out of range for type 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017 Workqueue: mt76 mt76utxstatusdata [mt76usb] Call Trace: <TASK> showstack+0x4e/0x61 dumpstacklvl+0x4a/0x6f dumpstack+0x10/0x18 ubsanepilogue+0x9/0x43 _ubsanhandleoutofbounds.cold+0x42/0x47 ieee80211getrateduration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211txstatusext+0x32e/0x640 [mac80211] ieee80211calcrxairtime+0xda/0x120 [mac80211] ieee80211calctxairtime+0xb4/0x100 [mac80211] mt76x02sendtxstatus+0x266/0x480 [mt76x02lib] mt76x02txstatusdata+0x52/0x80 [mt76x02lib] mt76utxstatusdata+0x67/0xd0 [mt76usb] processonework+0x225/0x400 workerthread+0x50/0x3e0 ? processonework+0x400/0x400 kthread+0xe9/0x110 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30(CVE-2022-49022)

In the Linux kernel, the following vulnerability has been resolved: ixgbevf: Fix resource leak in ixgbevfinitmodule() ixgbevfinitmodule() won't destroy the workqueue created by createsinglethreadworkqueue() when pciregisterdriver() failed. Add destroyworkqueue() in fail path to prevent the resource leak. Similar to the handling of u132hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")(CVE-2022-49028)

In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcmprocshow() BUG: KASAN: slab-use-after-free in bcmprocshow+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xd5/0x150 printreport+0xc1/0x5e0 kasanreport+0xba/0xf0 bcmprocshow+0x969/0xa80 seqreaditer+0x4f6/0x1260 seqread+0x165/0x210 procregread+0x227/0x300 vfsread+0x1d5/0x8d0 ksysread+0x11e/0x240 dosyscall64+0x35/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd Allocated by task 7846: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasankmalloc+0x9e/0xa0 bcmsendmsg+0x264b/0x44e0 socksendmsg+0xda/0x180 syssendmsg+0x735/0x920 syssendmsg+0x11d/0x1b0 _syssendmsg+0xfa/0x1d0 dosyscall64+0x35/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd Freed by task 7846: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x27/0x40 kasanslabfree+0x161/0x1c0 slabfreefreelisthook+0x119/0x220 _kmemcachefree+0xb4/0x2e0 rcucore+0x809/0x1bd0 bcmop is freed before procfs entry be removed in bcmrelease(), this lead to bcmprocshow() may read the freed bcmop.(CVE-2023-52922)

A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.(CVE-2023-6356)

A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.(CVE-2023-6535)

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

ice: protect XDP configuration with a mutex

The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler.

XDP setup and PF reset code access the same resources in the following sections: * icevsiclose() in iceprepareforreset() - already rtnl-locked * icevsirebuild() for the PF VSI - not protected * icevsi_open() - already rtnl-locked

With an unfortunate timing, such accesses can result in a crash such as the one below:

[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEMTYPEXSKBUFFPOOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEMTYPEXSKBUFFPOOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: txtimeout: VSInum: 6, Q 14, NTC: 0x0, HWHEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: txtimeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: errorcode(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice iceservicetask [ice] [ +0.000183] RIP: 0010:icecleantxring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +0.000014] ? _die+0x1f/0x70 [ +0.000029] ? pagefaultoops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? excpagefault+0x7b/0x180 [ +0.000022] ? asmexcpagefault+0x22/0x30 [ +0.000031] ? icecleantxring+0xa/0xd0 [ice] [ +0.000194] icefreetxring+0xe/0x60 [ice] [ +0.000186] icedestroyxdprings+0x157/0x310 [ice] [ +0.000151] icevsidecfg+0x53/0xe0 [ice] [ +0.000180] icevsirebuild+0x239/0x540 [ice] [ +0.000186] icevsirebuildbytype+0x76/0x180 [ice] [ +0.000145] icerebuild+0x18c/0x840 [ice] [ +0.000145] ? delaytsc+0x4a/0xc0 [ +0.000022] ? delaytsc+0x92/0xc0 [ +0.000020] icedoreset+0x140/0x180 [ice] [ +0.000886] iceservicetask+0x404/0x1030 [ice] [ +0.000824] processonework+0x171/0x340 [ +0.000685] workerthread+0x277/0x3a0 [ +0.000675] ? preemptcountadd+0x6a/0xa0 [ +0.000677] ? _rawspinlockirqsave+0x23/0x50 [ +0.000679] ? _pfxworkerthread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? _pfxkthread+0x10/0x10 [ +0.000616] retfromfork+0x2d/0x50 [ +0.000612] ? _pfxkthread+0x10/0x10 [ +0.000604] retfromforkasm+0x1b/0x30 [ +0.000604] </TASK>

The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway.

There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect icevsirebuild() with rtnl_lock().

Add xdpstatelock mutex to protect icevsirebuild() and ice_xdp().

Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open

The latter case is actually already handled through !netifrunning() case, we just need to adjust flag checking a little. The former one is not as trivial, because between icevsiclose() and icevsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion.

Therefore, add an additional VSI state flag ICEVSIREBUILDPENDING to indicate that icex ---truncated---(CVE-2024-46765)

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: 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: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpiofile := ALGN(4) + cpioheader + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 cnamesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's doname() path handler assumes a zero-terminated path at @collected, passing it directly to filpopen() / initmkdir() / initmknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfstestfnameoverrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @outbuf in _gunzip(), rather than the initrdstart+initrdsize block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfstestfnameoverrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in dosymlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)