OESA-2025-2056

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkmsexit() function might access an uninitialized or freed defaultconfig pointer and it might double free it.

Fix both possible errors by initializing default_config only when the driver initialization succeeded.(CVE-2025-22097)

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

wifi: at76c50x: fix use after free access in at76_disconnect

The memory pointed to by priv is freed at the end of at76deletedevice function (using ieee80211freehw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface.(CVE-2025-37796)

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

codel: remove sch->q.qlen check before qdisctreereduce_backlog()

After making all ->qlennotify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fqcodeldequeue() and codelqdisc_dequeue().(CVE-2025-37798)

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

net_sched: qfq: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of qfq, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.

This patch checks whether the class was already added to the agg->active list (clisactive) before doing the addition to cater for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37913)

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

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the class was already added to the activelist (clis_active) before adding to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)

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

RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction

The commit 59c68ac31e15 ("iwcm: free cmid resources on the last deref") simplified cmid resource management by freeing cmid once all references to the cmid were removed. The references are removed either upon completion of iwcm event handlers or when the application destroys the cmid. This commit introduced the use-after-free condition where cmidprivate object could still be in use by event handler works during the destruction of cmid. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction.

However, still another use-after-free possibility remained. It happens with the work objects allocated for each cmidpriv within allocworkentries() during cmid creation, and subsequently freed in deallocworkentries() once all references to the cmid are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:

BUG: KASAN: slab-use-after-free in _pwqactivate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iwcmwq) Call Trace: <TASK> dumpstacklvl+0x6a/0x90 printreport+0x174/0x554 ? _virtaddrvalid+0x208/0x430 ? _pwqactivatework+0x1ff/0x250 kasanreport+0xae/0x170 ? _pwqactivatework+0x1ff/0x250 _pwqactivatework+0x1ff/0x250 pwqdecnrinflight+0x8c5/0xfb0 processonework+0xc11/0x1460 ? _pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5ef/0xfd0 ? _pfxworkerthread+0x10/0x10 kthread+0x3b0/0x770 ? _pfxkthread+0x10/0x10 ? rcuiswatching+0x11/0xb0 ? _rawspinunlockirq+0x24/0x50 ? rcuiswatching+0x11/0xb0 ? _pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 147416: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 _kasankmalloc+0xa6/0xb0 allocworkentries+0xa9/0x260 [iwcm] iwcmconnect+0x23/0x4a0 [iwcm] rdmaconnectlocked+0xbfd/0x1920 [rdmacm] nvmerdmacmhandler+0x8e5/0x1b60 [nvmerdma] cmacmeventhandler+0xae/0x320 [rdmacm] cmaworkhandler+0x106/0x1b0 [rdmacm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Freed by task 147091: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 _kasanslabfree+0x4b/0x70 kfree+0x13a/0x4b0 deallocworkentries+0x125/0x1f0 [iwcm] iwcmderefid+0x6f/0xa0 [iwcm] cmworkhandler+0x136/0x1ba0 [iwcm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromfork_asm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x2c/0x50 kasanrecordauxstack+0xa3/0xb0 _queuework+0x2ff/0x1390 queueworkon+0x67/0xc0 cmeventhandler+0x46a/0x820 [iwcm] siwcmupcall+0x330/0x650 [siw] siwcmworkhandler+0x6b9/0x2b20 [siw] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromfork_asm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.

To avoid the use-after-free of cmidprivate work objects, ensure that the last reference to the cmid is decremented not in the event handler works, but in the cmid destruction context. For that purpose, mo ---truncated---(CVE-2025-38211)

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

atm: clip: prevent NULL deref in clip_push()

Blamed commit missed that vccdestroysocket() calls clip_push() with a NULL skb.

If clipdevs is NULL, clippush() then crashes when reading skb->truesize.(CVE-2025-38251)

A vulnerability was found in Linux Kernel up to 6.16-rc4 (Operating System) and classified as problematic.Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.Impacted is confidentiality.Upgrading to version 5.15.189, 6.1.144, 6.6.97, 6.12.37, 6.15.6 or 6.16-rc5 eliminates this vulnerability. Applying the patch 982beb7582c193544eb9c6083937ec5ac1c9d651/6aca3dad2145e864dfe4d1060f45eb1bac75dd58/80b971be4c37a4d23a7f1abc5ff33dc7733d649b/bc68bc3563344ccdc57d1961457cdeecab8f81ef/11f2d0e8be2b5e784ac45fa3da226492c3e506d8/315dbdd7cdf6aa533829774caaf4d25f1fd20e73 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38375)

A vulnerability was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch ac3a8147bb24314fb3e84986590148e79f9872ec/c4f16f6b071a74ac7eefe5c28985285cbbe2cd96/b97be7ee8a1cd96b89817cbd64a9f5cc16c17d08/6d63901dcd592a1e3f71d7c6d78f9be5e8d7eef0/a0075accbf0d76c2dad1ad3993d2e944505d99a0 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38473)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.1.146/6.6.99/6.12.39/6.15.7 (Operating System).CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.147, 6.6.100, 6.12.40 or 6.15.8 eliminates this vulnerability. Applying the patch d3ed1d84a84538a39b3eb2055d6a97a936c108f2/fcda39a9c5b834346088c14b1374336b079466c1/a262370f385e53ff7470efdcdaf40468e5756717/a47d9d9895bad9ce0e840a39836f19ca0b2a343a/4f15ee98304b96e164ff2340e1dfd6181c3f42aa is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38495)

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

bpf: Reject %p% format string in bprintf-like helpers

static const char fmt[] = "%p%"; bpftraceprintk(fmt, sizeof(fmt));

The above BPF program isn't rejected and causes a kernel warning at runtime:

Please remove unsupported %\x00 in format string
WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0

This happens because bpfbprintfprepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\x00 is then processed in the next iteration and rejected.(CVE-2025-38528)