CVE-2026-99252

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) 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.