Skip to main content
← Vulnerabilities

io_uring/mpscq: disable preemption while pushing

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
25Pcve.now Index 25 of 100 · methodology v3 · provisional
  • Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
  • Exposure?/25Exposure: unknown (data gap). No advisory context yet
  • Reach20/20Affects Linux kernel (software on nearly every server, desktop or phone)
  • Severity?/10Severity: unknown (data gap). No CVSS score or vendor rating
  • No patch5/5No patch listed yet

What would change the score

  • Would score about 80 if added to CISA KEV
  • Would score about 75 if CISA's SSVC rates exploitation active
  • Would score about 47 if advisories confirm default setups are exposed

CVE-2026-99252 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It affects Linux; no fixed version is listed yet.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

The Linux kernel's io_uring subsystem, specifically its multi-producer single-consumer queue used for local task work, is affected. A higher-priority consumer on the same CPU can spin indefinitely while a preempted producer has not yet linked its queued node, which can stall the consumer and hang the affected io_uring process.

Read the original description

In the Linux kernel, the following vulnerability has been resolved: io_uring/mpscq: disable preemption while pushing A push makes the node the new tail, and then links it to its predecessor. In between the queue isn't empty, but mpscq_pop() can't get at the node. The consumers deal with that by trying again, with a cond_resched() in the loop to give a preempted producer the chance to finish. cond_resched() doesn't do that if the consumer has a higher priority than the producer and both have to use the same CPU: producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) <preempted> io_cqring_wait() __io_run_local_work() again: cond_resched() // nothing to do mpscq_pop() // NULL // work pending, no events yet goto again The producer can be any task that is able to queue task_work for the ring: an io-wq worker, or somebody who sends a message with IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the scheduler takes pity on the fair class, which takes about a second with the default settings of the fair server, and forever without it. The loops in tctx_task_work_run() and io_cancel_local_task_work() have the same problem. Don't allow preemption between the two steps. That bounds the time the window is open on the CPU of the producer by what interrupts take, and a consumer that waits for that is on another CPU. The cost is a preempt_disable()/preempt_enable() pair per push.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. Record last updated

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    7.2

Evidence 2

  1. Link
  2. Link

Corrections

None so far.

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

FAQ

Questions about CVE-2026-99252

Is CVE-2026-99252 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

Which versions are affected by CVE-2026-99252?

Linux: version 7.2.Source: cve.now feed data