In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.
irq_exit()
__irq_exit_rcu()
/* in_hardirq() returns false after this */
preempt_count_sub(HARDIRQ_OFFSET)
tick_irq_exit()
tick_nohz_irq_exit()
tick_nohz_stop_sched_tick()
trace_tick_stop() /* a bpf prog is hooked on this trace point */
__bpf_trace_tick_stop()
bpf_trace_run2()
rcu_read_unlock_special()
/* will send a IPI to itself */
irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void)
{
+ rcu_read_lock();
+ WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
+ rcu_read_unlock();
+
[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]
References
Configurations
Configuration 1 (hide)
|
History
30 Oct 2026, 13:18
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
19 Oct 2026, 21:10
| Type | Values Removed | Values Added |
|---|---|---|
| Summary |
|
Information
Published : 2025-09-11 17:15
Updated : 2026-10-30 13:18
NVD link : CVE-2025-39744
Mitre link : CVE-2025-39744
CVE.ORG link : CVE-2025-39744
JSON object : View
Products Affected
linux
- linux_kernel
CWE
CWE-125
Out-of-bounds Read