Skip to main content
← Vulnerabilities

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.

—Not rated
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.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
Unclear
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

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    5.12

Evidence 5

  1. Link
  2. Link
  3. Link
  4. Link
  5. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

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