Look up another CVE · open CVE-2026-64073 in the interactive tracker
CVE-2026-64073
irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem kernel. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64073 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/irq_work.c
- What this is
- THE RESTMAINTAINERS section matched on */ · linux-kernel@vger.kernel.org · Buried alive in reporters
Check it on the machine
grep -w CONFIG_IRQ_WORK /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_IRQ_WORK
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.16 | 6.1.175 | 2dc793623029 |
| 5.16 | 6.6.142 | eef4f71b46a9 |
| 5.16 | 6.12.92 | 684a78183c54 |
| 5.16 | 6.18.34 | 18c0456ea261 |
| 5.16 | 7.0.11 | 81b582784518 |
| 5.16 | 7.1 | 91840be8f710 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires reaching irq_work_sync() teardown paths via local syscalls (e.g. perf_event_open/close, bpf map teardown) that queue non-HARD irq_work on PREEMPT_RT; there is no direct network packet or remote-protocol entry point into irq_work.c.
- AC:LAttack complexity, low
- The bug is a cross-CPU race where irq_work_sync() returns after BUSY is cleared while irq_work_single() still dereferences the work; an attacker can control both sides by concurrently closing/freeing a subsystem object and driving irq_work_queue() from another thread/CPU (e.g. perf fasync wakeup vs. close).
- PR:LPrivileges required, low
- Unprivileged local users can reach vulnerable teardown via perf_event_open/close on per-task events (exclude_kernel=1, default paranoid=2) and via bpf() ringbuf/map cleanup when CAP_BPF is available in a user namespace; no init-namespace root is required for the highest-impact paths.
- UI:NUser interaction, none
- Exploitation is driven entirely by the attacker's own syscalls and threading; no victim interaction such as opening files or mounting filesystems is needed.
- S:UScope, unchanged
- Successful exploitation corrupts or reads kernel memory and can yield local privilege escalation within the same kernel security authority; it does not inherently cross a VM/host, IOMMU, or container boundary by itself.
- C:HConfidentiality impact, high
- This is a kernel heap use-after-free: irq_work_single() dereferences a freed irq_work embedded in structures like perf_event or bpf_ringbuf, enabling arbitrary kernel memory disclosure through heap reuse and controlled reads of stale object fields.
- I:HIntegrity impact, high
- The UAF permits attacker-controlled reallocation of the freed irq_work container object, providing a standard kernel heap corruption primitive that can be developed into arbitrary write or control-flow hijack, not merely a bounded modification.
- A:HAvailability impact, high
- Use-after-free in irq_work_single() can immediately fault or panic the kernel during post-BUSY dereferences, and repeated triggering via perf/BPF open-close races can cause persistent denial of service on PREEMPT_RT systems.