OESA-2026-1505

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled xdpredirectcpu with some RT threads:

------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpumapkthreadstop RIP: 0010:putcpumapentry+0xda/0x220 ...... Call Trace: <TASK> ? showregs+0x65/0x70 ? _warn+0xa5/0x240 ...... ? putcpumapentry+0xda/0x220 cpumapkthreadstop+0x41/0x60 processonework+0x6b0/0xb80 workerthread+0x96/0x720 kthread+0x1a5/0x1f0 retfromfork+0x3a/0x70 retfromforkasm+0x1b/0x30 </TASK>

The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory leak in cpumapupdateelem"). The kthread is stopped prematurely by kthreadstop() in cpumapkthreadstop(), and kthread() doesn't call cpumapkthreadrun() at all but XDP program has already queued some frames or skbs into ptrring. So when _cpumapringcleanup() checks the ptrring, it will find it was not emptied and report a warning.

An alternative fix is to use _cpumapringcleanup() to drop these pending frames or skbs when kthreadstop() returns -EINTR, but it may confuse the user, because these frames or skbs have been handled correctly by XDP program. So instead of dropping these frames or skbs, just make sure the per-cpu kthread is running before _cpumapentry_alloc() returns.

After apply the fix, the error handle for kthread_stop() will be unnecessary because it will always return 0, so just remove it.(CVE-2023-53577)

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

drivers: base: Free devm resources when unregistering a device

In the current code, devresreleaseall() only gets called if the device has a bus and has been probed.

This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example.

We should thus call devresreleaseall() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver.

This is effectively the same change than commit 2f8d16a996da ("devres: release resources on devicedel()") that got reverted by commit a525a3ddeaca ("driver core: free devres in devicerelease") over memory leaks concerns.

This patch effectively combines the two commits mentioned above to release the resources both on devicedel() and devicerelease() and get the best of both worlds.(CVE-2023-53596)

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

dmaengine: mmppdma: Fix race condition in mmppdma_residue()

Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.

The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors:

CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapool_free(sw) <- FREED! -> access sw->desc <- UAF!

This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).

Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.(CVE-2025-71221)

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

migrate: correct lock ordering for hugetlb file folios

Syzbot has found a deadlock (analyzed by Lance Yang):

1) Task (5749): Holds foliolock, then tries to acquire immaprwsem(read lock). 2) Task (5754): Holds immaprwsem(write lock), then tries to acquire foliolock.

migratepages() -> migratehugetlbs() -> unmapandmovehugepage() <- Takes foliolock! -> removemigrationptes() -> _rmapwalkfile() -> immaplockread() <- Waits for immap_rwsem(read lock)!

hugetlbfsfallocate() -> hugetlbfspunchhole() <- Takes immaprwsem(write lock)! -> hugetlbfszeropartialpage() -> filemaplockhugetlbfolio() -> filemaplockfolio() -> _filemapgetfolio <- Waits for folio_lock!

The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing immaplock to cover the calls to removemigrationptes() too.

This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.(CVE-2026-23097)

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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to _copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.(CVE-2026-23112)

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

scsi: target: iscsi: Fix use-after-free in iscsitdecconnusagecount()

In iscsitdecconnusagecount(), the function calls complete() while holding the conn->connusagelock. As soon as complete() is invoked, the waiter (such as iscsitcloseconnection()) may wake up and proceed to free the iscsit_conn structure.

If the waiter frees the memory before the current thread reaches spinunlockbh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.

Fix this by releasing the spinlock before calling complete().(CVE-2026-23216)