7.8 HIGH
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Local (L)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L)
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): High (H)
- Integrity (I): High (H)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Local (L)
- Modified Attack Complexity (MAC): Low (L)
- Modified Privileges Required (MPR): Low (L)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): High (H)
- Modified Scope (MS): Unchanged (U)
- Modified Integrity (MI): High (H)
- Modified Availability (MA): High (H)
Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
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.
References
Affected products
- <684a78183c54c23e70d1cba320f7fc184604210b
- <2dc79362302922cb18f35e262712b5e58de65442
- =<6.18.*
- =<7.0.*
- <81b582784518196eff1050212a046bc29d3a05dd
- =<6.12.*
- <5.16
- =<6.1.*
- =<6.6.*
- =<*
- <18c0456ea2615b1a743a6db739c74411c3b42bc6
- ==5.16
- <91840be8f710370607f949a627e070896faeddb8
- <eef4f71b46a9929ac33e968538c9dd5d96a02460