CVE-2025-39744

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Fix rcu_read_unlock() deadloop due to IRQ work<br /> <br /> During rcu_read_unlock_special(), if this happens during irq_exit(), we<br /> can lockup if an IPI is issued. This is because the IPI itself triggers<br /> the irq_exit() path causing a recursive lock up.<br /> <br /> This is precisely what Xiongfeng found when invoking a BPF program on<br /> the trace_tick_stop() tracepoint As shown in the trace below. Fix by<br /> managing the irq_work state correctly.<br /> <br /> irq_exit()<br /> __irq_exit_rcu()<br /> /* in_hardirq() returns false after this */<br /> preempt_count_sub(HARDIRQ_OFFSET)<br /> tick_irq_exit()<br /> tick_nohz_irq_exit()<br /> tick_nohz_stop_sched_tick()<br /> trace_tick_stop() /* a bpf prog is hooked on this trace point */<br /> __bpf_trace_tick_stop()<br /> bpf_trace_run2()<br /> rcu_read_unlock_special()<br /> /* will send a IPI to itself */<br /> irq_work_queue_on(&amp;rdp-&gt;defer_qs_iw, rdp-&gt;cpu);<br /> <br /> A simple reproducer can also be obtained by doing the following in<br /> tick_irq_exit(). It will hang on boot without the patch:<br /> <br /> static inline void tick_irq_exit(void)<br /> {<br /> + rcu_read_lock();<br /> + WRITE_ONCE(current-&gt;rcu_read_unlock_special.b.need_qs, true);<br /> + rcu_read_unlock();<br /> +<br /> <br /> [neeraj: Apply Frederic&amp;#39;s suggested fix for PREEMPT_RT]