CVE-2025-39744

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 Frederics suggested fix for PREEMPT_RT]

Affected Software

References

• https://git.kernel.org/stable/c/1cfa244f7198d325594e627574930b7b91df5bfe
• https://git.kernel.org/stable/c/56c5ef194f4509df63fc0f7a91ea5973ce479b1e
• https://git.kernel.org/stable/c/b41642c87716bbd09797b1e4ea7d904f06c39b7b
• https://git.kernel.org/stable/c/ddebb2a7677673cf4438a04e1a48b8ed6b0c8e9a
• https://git.kernel.org/stable/c/e7a375453cca2b8a0d2fa1b82b913f3fed7c0507