In the Linux kernel, the following vulnerability has been resolved:
iouring/zcrx: fix userref race between scrub and refill paths
The iozcrxputniovuref() function uses a non-atomic check-then-decrement pattern (atomicread followed by separate atomicdec) to manipulate userrefs. This is serialized against other callers by rqlock, but iozcrxscrub() modifies the same counter with atomicxchg() WITHOUT holding rqlock.
On SMP systems, the following race exists:
CPU0 (refill, holds rqlock) CPU1 (scrub, no rqlock) putniovuref: atomicread(uref) - 1 // window opens atomicxchg(uref, 0) - 1 returnniovfreelist(niov) [PUSH #1] // window closes atomicdec(uref) - wraps to -1 returns true returnniov(niov) returnniovfreelist(niov) [PUSH #2: DOUBLE-FREE]
The same niov is pushed to the freelist twice, causing freecount to exceed nriovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object.
Fix this by replacing the non-atomic read-then-dec in iozcrxputniovuref() with an atomictrycmpxchg loop that atomically tests and decrements userrefs. This makes the operation safe against concurrent atomicxchg from scrub without requiring scrub to acquire rq_lock.
[pavel: removed a warning and a comment]
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43121.json"
}