CVE-2025-39744

Technical Description

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

Remediation

Check the references section for vendor advisories and patches from linux. Update linux_kernel to the latest patched version. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

Affected Products

References