io_uring/cmd: don't leave list poison in ->hash_node
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: The checked facts give no workaround and no fix. Nothing in them says how to limit the affected feature while waiting for a patch.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 25/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's io_uring subsystem, which handles asynchronous I/O, is affected. A specific flaw in how it reuses internal command and futex request structures can cause a crash (kernel fault) when a vectored futex wait completes, leading to a denial of service.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd: don't leave list poison in ->hash_node io_uring_cmd_del_cancelable() uses hlist_del() to take a command off ->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in ->hash_node. Requests are recycled through the request cache without being reinitialised, and not every user of ->hash_node sets it up before it is used: If a vectored futex wait is woken while futex_wait_multiple_setup() is still queueing the futexes, io_futexv_wait() doesn't add the request to ->futex_list, and leaves the completion to the task_work queued by the wake up. io_futexv_complete() ends in __io_futex_complete(), whose hlist_del_init() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through LIST_POISON2: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...] RIP: 0010:io_futexv_complete+0x219/0x420 Call Trace: tctx_task_work_run+0x804/0x950 tctx_task_work+0x71/0xa0 task_work_run+0x118/0x200 Leave the node unhashed.
What to do
Workaround: The checked facts give no workaround and no fix. Nothing in them says how to limit the affected feature while waiting for a patch.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
6.7
Evidence 3
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99230
What does this mean?
The bug can make the Linux kernel hit a general protection fault (an oops) and crash. It happens when a recycled io_uring request still holds a list poison pointer in its ->hash_node field, and the kernel then writes through that pointer.Source: git.kernel.org
Am I affected, and how do I check?
The checked facts list Linux kernel with no version ranges, so the affected versions are not stated. The bug needs a vectored futex wait woken while futex_wait_multiple_setup() is still queueing futexes, and a request recycled from a cancelable uring_cmd such as a ublk FETCH_REQ. To check a system, compare its kernel version with the ranges in the kernel advisory, which the checked facts do not include.Source: git.kernel.org
What should I do about it?
The checked facts name no fixed kernel version, so no upgrade target can be given from them. Use the kernel vendor's or distribution's advisory for the fixed version once it is available.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
The checked facts give no workaround and no fix. Nothing in them says how to limit the affected feature while waiting for a patch.Source: git.kernel.org