UBUNTU-CVE-2026-99252: Medium severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: iouring/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 mpscqpop() can't get at the node. The consumers deal with that by trying again, with a condresched() in the loop to give a preempted producer the chance to finish. condresched() doesn't do that if the consumer has a higher priority than the producer and both have to use the same CPU: producer (SCHEDOTHER) consumer (SCHEDFIFO), same CPU ioreqlocalworkadd() mpscqpush() prev = xchg(&q->tail, node) <preempted> iocqringwait() iorunlocalwork() again: condresched() // nothing to do mpscqpop() // NULL // work pending, no events yet goto again The producer can be any task that is able to queue taskwork for the ring: an io-wq worker, or somebody who sends a message with IORINGOPMSGRING. The consumer spins, holding ->uringlock, 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 tctxtaskworkrun() and iocancellocaltaskwork() 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 preemptdisable()/preemptenable() pair per push.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Disable preemption for the entire mpscq push operation, covering the exchange that makes the node the new tail and linking it to its predecessor; re-enable preemption afterward with a preempt_disable()/preempt_enable() pair.
Event History
Frequently Asked Questions
What conditions are needed to trigger the scheduling stall?
The producer and consumer must run on the same CPU, with a SCHED_OTHER producer preempted after updating the queue tail and a higher-priority SCHED_FIFO consumer attempting to consume the work. The producer can be an io-wq worker or a task able to queue task_work through IORING_OP_MSG_RING.
How long can the affected consumer remain stuck?
With the default fair-server settings, the scheduler may allow the producer to run after about one second. Without the fair server, the consumer can spin indefinitely while holding the uring_lock.
Which Ubuntu kernel package families are listed as affected?
The listed package families are linux, linux-fips, linux-aws, linux-azure, linux-gcp, linux-oracle, linux-aws-fips, and linux-azure-fips.