7.8
CVE-2026-64073
- EPSS 0.13%
- Veröffentlicht 19.07.2026 15:39:48
- Zuletzt bearbeitet 16.10.2026 16:19:05
- Erkennungen
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.
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 5.16 < 6.1.175
Linux ≫ Linux Kernel Version >= 6.2 < 6.6.142
Linux ≫ Linux Kernel Version >= 6.7 < 6.12.92
Linux ≫ Linux Kernel Version >= 6.13 < 6.18.34
Linux ≫ Linux Kernel Version >= 6.19 < 7.0.11
Linux ≫ Linux Kernel Version 7.1 Update rc1
Linux ≫ Linux Kernel Version 7.1 Update rc2
Linux ≫ Linux Kernel Version 7.1 Update rc3
VulnDex Vulnerability Enrichment
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.13% | 0.032 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 1.8 | 5.9 |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
|
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
https://git.kernel.org/stable/c/2dc79362302922cb18f35e262712b5e58de65442
https://git.kernel.org/stable/c/eef4f71b46a9929ac33e968538c9dd5d96a02460
https://git.kernel.org/stable/c/684a78183c54c23e70d1cba320f7fc184604210b
https://git.kernel.org/stable/c/18c0456ea2615b1a743a6db739c74411c3b42bc6
https://git.kernel.org/stable/c/81b582784518196eff1050212a046bc29d3a05dd
https://git.kernel.org/stable/c/91840be8f710370607f949a627e070896faeddb8