CVE-2026-99230

What it actually does

Use-after-free in io_uring request recycling: hlist_del() from io_uring_cmd_del_cancelable() leaves LIST_POISON values in ->hash_node; recycled requests reused in io_futexv paths without reinitialization cause wild-memory writes through poisoned pointers in __io_futex_complete().

Why it matters to the business

Local attackers can crash the kernel or potentially escalate privileges on any Linux system using io_uring and futex operations; the flaw is only one day old with no public exploits yet, giving defenders a short window before weaponization.

How an attack unfolds

An attacker issues a cancelable uring command (e.g., ublk FETCH_REQ) that is later removed via hlist_del(), leaving poison in the request's hash_node. The request is returned to the cache and reallocated for a vectored futex wait. When the futex wake-up races with setup, io_futexv_complete() calls hlist_del_init() on the poisoned node, dereferencing LIST_POISON2 and triggering a general protection fault that can be turned into controlled memory corruption for privilege escalation.

How to fix it

Upgrade to a kernel containing the fix that ensures ->hash_node is left in an unhashed state (hlist_del_init or equivalent) for all io_uring command paths; rebuild and reboot affected systems; prioritize servers and containers that expose io_uring to untrusted workloads.

How to confirm the fix worked

Confirm the patch is present by inspecting the io_uring/cmd.c source for the corrected io_uring_cmd_del_cancelable() logic that avoids leaving poison; run kernel regression tests exercising io_uring cancelable commands concurrent with futex waits; verify no LIST_POISON dereferences occur under load.

Typical attack path

1. Submit cancelable io_uring command that populates ->hash_node
2. Trigger io_uring_cmd_del_cancelable() leaving LIST_POISON in the node
3. Force request recycling through the io_uring request cache
4. Allocate the poisoned request for a concurrent vectored futex wait
5. Race the wake-up so io_futexv_complete() dereferences the poisoned node
6. Exploit resulting wild-memory write for kernel code execution

How to detect it

Search kernel logs and crash dumps for the exact call trace containing io_futexv_complete, tctx_task_work_run, and wild-memory-access or KASAN reports involving LIST_POISON addresses; correlate with processes that use io_uring and futex syscalls.

What your security team should do

• Apply the upstream fix within 7 days given the one-day publication age and use-after-free class
• Disable io_uring via seccomp or sysctl where not required until patched
• Monitor kernel oops logs for io_futexv_complete and tctx_task_work_run signatures
• Audit workloads using ublk or other cancelable uring commands for exposure