CVE-2026-64073: irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT
On PREEMPTRT, non-HARD irqwork runs in per-CPU kthreads via runirqworkd(), so irqworksync() uses rcuwait() to wait for BUSY==0.
After irqworksingle() clears BUSY via atomiccmpxchg(), it still dereferences @work for irqworkishard() and rcuwaitwakeup().
An irqworksync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.
Fix this by wrapping runirqworkd() in guard(rcu)() so that the entire irqworksingle() execution is within an RCU read-side critical section. Then add synchronizercu() in irqworksync() after rcuwaitwaitevent() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems using PREEMPT_RT, where non-HARD irq_work executes through per-CPU kthreads. The described race involves irq_work_single() and a concurrent irq_work_sync() caller on another CPU.
What conditions are needed to trigger the use-after-free?
A caller on another CPU must enter irq_work_sync() after irq_work_single() has cleared the BUSY flag but before irq_work_single() finishes accessing the work item. The synchronizing caller can then see BUSY==0, return, and free the work item while it is still being dereferenced.
What is the remediation implemented by the fix?
The fix keeps the full irq_work_single() execution inside an RCU read-side critical section when run from run_irq_workd(). It also makes irq_work_sync() wait for an RCU grace period after waiting for BUSY to clear, preventing the work item from being freed too early.