io_uring/io-wq: don't lose the signal that ends work
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 facts list no workaround. The bug needs a FIFO open with no writer submitted with IOSQE_ASYNC, so avoiding that combination limits exposure, but no vendor-recommended workaround is given.
- 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 (its io-wq worker threads) is affected. A thread that exits while submitting a blocking open, such as opening a FIFO with no writer, can hang indefinitely in the kernel during exit until the process is forcibly killed, which can stall the process and tie up its resources.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: don't lose the signal that ends work When a thread exits, only its tracked requests are cancelled. Then its io-wq is torn down. io_wq_exit_workers() signals every worker, to get it out of an interruptible sleep, and waits for all of them to exit. Before they do, they go through the work that is left. Unbounded work is cancelled. Bounded work is run, as it is expected to end by itself. Not all of it does. An open has no file yet, so it counts as bounded, and the open of a FIFO waits for the other end. That is what the signal is for. But the workers are signalled once, and a worker that hasn't started the work by then loses the signal: io_wq_exit_workers() io_worker_handle_work() io_wq_worker_wake() set TIF_NOTIFY_SIGNAL io_assign_current_work() io_run_task_work() clear TIF_NOTIFY_SIGNAL io_wq_submit_work() fifo_open() wait_for_partner() wait_for_completion_timeout() The thread never gets out of do_exit(): IORING_OP_OPENAT of a FIFO without a writer, IOSQE_ASYNC exit of the thread that has submitted it hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is killed. Set TIF_NOTIFY_SIGNAL for bounded work that is started with IO_WQ_BIT_EXIT set. The bit is set before the workers are signalled, and it is tested after the flag has been cleared, with clear_notify_signal() providing the barrier. So either the flag stays, or the bit is seen. Work that is started while the io-wq exits is treated like work that is being run at that time: it isn't interrupted unless it waits interruptibly.
What to do
Workaround: The facts list no workaround. The bug needs a FIFO open with no writer submitted with IOSQE_ASYNC, so avoiding that combination limits exposure, but no vendor-recommended workaround is given.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
5.12
Evidence 5
- Link
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99228
What does this mean?
An io_uring open of a FIFO that has no writer, submitted with IOSQE_ASYNC, can lose the signal that ends the work if the submitting thread exits while the open is still pending. The exiting thread then hangs in do_exit() and cannot finish exiting until the process is killed.Source: git.kernel.org
Am I affected, and how do I check?
The facts name only the Linux kernel and give no version ranges. The affected setup is an IORING_OP_OPENAT of a FIFO without a writer, submitted with IOSQE_ASYNC, where the submitting thread exits before the open completes. To check a kernel, compare its version with the kernel vendor's advisory for this CVE, since the facts list no affected versions.Source: git.kernel.org
What should I do about it?
No fixed version is listed in the facts, so no upgrade target can be named. Check the kernel vendor's updates for a fix to this CVE.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 facts list no workaround. The bug needs a FIFO open with no writer submitted with IOSQE_ASYNC, so avoiding that combination limits exposure, but no vendor-recommended workaround is given.Source: git.kernel.org