AZL-112592: CVE-2026-99243 affecting package kernel 6.6.159.1-1
In the Linux kernel, the following vulnerability has been resolved:
io-wq: order the exit bit against worker creation task work
iowqexitworkers() cancels task work for queued worker creation with taskworkcancelmatch(). That has a plain load of task->taskworks.
ioqueueworkercreate() adds the new entry and tests IOWQBITEXIT to cancel it if the workqueue is already on its way out.
That must be ordered. taskworkadd() has a full barrier via cmpxchg(). But iowqexitstart() sets the bit with setbit() which doesn't have any memory ordering.
So afaict, on weakly ordered architectures the exiting task may load taskworks before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with workerrefs and the exiting task waits on workerdone indefinitely.
If the task still has rings then iouringdeltctxnode() provides the barrier via testandsetbit() in iowqsetexitonidle(). When it has closed all rings though that barrier is gone.
Add the barrier after the setbit().
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using io_uring and io-wq worker creation during workqueue teardown are affected by the described race. The issue is specifically relevant on weakly ordered architectures, and the missing ordering is exposed when the task has closed all of its rings.
What condition triggers the failure?
A worker-creation task work entry must be queued while io-wq exit is beginning, with both sides observing stale ordering around the exit bit. The queued entry can remain present with worker references after cancellation is attempted.
What is the operational impact if the race occurs?
The exiting task can wait indefinitely for worker completion because worker_refs remains associated with the queued worker-creation entry. This results in a hang during workqueue shutdown or task exit.