Live › vulnerability › CVE-2026-99252
A race in the Linux kernel's io_uring lockless queue lets a higher-priority task on the same CPU spin forever while a preempted producer has not finished linking a node. The sources describe a hang or denial of service, not code execution or data theft.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 12:20 UTC. All times on this page are UTC.
Systems running a Linux kernel with io_uring where a SCHED_FIFO task and a SCHED_OTHER producer share a CPU, such as code that waits on io_uring completions with real-time priorities. The sources do not give the affected version ranges. Systems that do not use io_uring are not affected.
No product ranges from the sources yet.
uname -r and compare it against the fixed kernel releases in the sources.io_uring_disabled is set in /proc/sys/kernel/io_uring_disabled.Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99252")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.