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:
irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via
run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.
After irq_work_single() clears BUSY via atomic_cmpxchg(), it still
dereferences @work for irq_work_is_hard() and rcuwait_wake_up().
An irq_work_sync() 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 run_irq_workd() in guard(rcu)() so that the entire
irq_work_single() execution is within an RCU read-side critical
section. Then add synchronize_rcu() in irq_work_sync() after
rcuwait_wait_event() to ensure the caller waits for the RCU grace period
before returning, preventing premature frees.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel use-after-free flaw in PREEMPT_RT behavior. A local authenticated user could potentially trigger memory corruption with high impact to confidentiality, integrity, and availability. Exposure depends on running an affected Linux kernel with the relevant real-time irq_work path.
Executive priority
Treat as high priority for Linux real-time workloads and multi-user systems. Patch through normal emergency kernel update processes once vendor packages are available, but do not claim internet-wide urgency without exposure evidence.
Technical view
On PREEMPT_RT, non-HARD irq_work runs through per-CPU kthreads. irq_work_single() clears BUSY, then still dereferences work. A concurrent irq_work_sync() caller can observe BUSY cleared, return, and free the object first. The fix keeps irq_work_single() within RCU protection and adds synchronize_rcu() before irq_work_sync() returns.
Likely exposure
Most relevant to Linux systems using PREEMPT_RT or kernels carrying this irq_work implementation. The source bundle names Linux kernel versions and stable commits, but distro package mappings and default RT configuration exposure are not provided.
Exploitation context
The CVSS vector is local, low complexity, low privileges, no user interaction, with high CIA impact. The bundle says KEV is false and provides no evidence of active exploitation or public exploit availability.
Researcher notes
The vulnerable window is after BUSY is cleared in irq_work_single() but before later work dereferences complete. The remediation strategy is lifetime protection with RCU around run_irq_workd() and a grace-period wait in irq_work_sync().
Mitigation direction
Apply Linux kernel updates that include the referenced stable fixes.
Prioritize systems using PREEMPT_RT or real-time kernels.
Reboot systems into the fixed kernel after updating.
Check distribution or vendor advisories for exact package names and fixed versions.
Use vendor guidance for any temporary mitigation if patching is delayed.
Validation and detection
Inventory Linux kernel versions across affected fleets.
Identify hosts using PREEMPT_RT or real-time kernel builds.
Confirm installed kernels include one of the referenced stable fix commits.
Verify systems are booted into the updated kernel, not only patched on disk.
Track CVE and vendor advisories for package-specific status.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-64073 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.