PT-2026-37461 · Linux · Linux+1
Pavel
·
Published
2026-05-06
·
Updated
2026-05-14
·
CVE-2026-43121
CVSS v3.1
4.7
Medium
| Vector | AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H |
In the Linux kernel, the following vulnerability has been resolved:
io uring/zcrx: fix user ref race between scrub and refill paths
The io zcrx put niov uref() function uses a non-atomic
check-then-decrement pattern (atomic read followed by separate
atomic dec) to manipulate user refs. This is serialized against other
callers by rq lock, but io zcrx scrub() modifies the same counter with
atomic xchg() WITHOUT holding rq lock.
On SMP systems, the following race exists:
CPU0 (refill, holds rq lock) CPU1 (scrub, no rq lock)
put niov uref:
atomic read(uref) - 1
// window opens
atomic xchg(uref, 0) - 1
return niov freelist(niov) [PUSH #1]
// window closes
atomic dec(uref) - wraps to -1
returns true
return niov(niov)
return niov freelist(niov) [PUSH #2: DOUBLE-FREE]
The same niov is pushed to the freelist twice, causing free count to
exceed nr iovs. 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
io zcrx put niov uref() with an atomic try cmpxchg loop that atomically
tests and decrements user refs. This makes the operation safe against
concurrent atomic xchg from scrub without requiring scrub to acquire
rq lock.
[pavel: removed a warning and a comment]
Fix
Race Condition
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Linux
Linux Kernel