CVE-2025-39744

What it actually does

Causes a deadlock in RCU read unlock during IRQ exit when an IPI is queued from rcu_read_unlock_special, leading to recursive invocation of the irq_exit path.

Why it matters to the business

System hangs or lockups on affected Linux kernels, particularly when using BPF tracing or similar workloads, impacting availability of services, containers, and clusters; widespread downstream dependents increase exposure across many environments.

How an attack unfolds

A program (such as a BPF hook on trace_tick_stop) triggers rcu_read_unlock_special during irq_exit, queuing an IPI to the same CPU that recurses into the same path and hangs the system. Threat actors including VMSCAPE and those exploiting related Linux kernel issues on container-optimized OS may leverage similar race conditions for denial of service or escalation.

How to fix it

Upgrade the Linux kernel to commit e7a375453cca2b8a0d2fa1b82b913f3fed7c0507; update kubernetes-1.32, kubectl-1.32, kube-scheduler-1.32, kube-controller-manager-1.32 and kube-apiserver-1.32 to 1.32.7-r0.

How to confirm the fix worked

Confirm updated kernel or package versions are running; reproduce the provided tick_irq_exit test case to verify the hang no longer occurs.

Typical attack path

1. Trigger interrupt exit path via tick handling or tracepoint
2. Execute code that sets need_qs and calls rcu_read_unlock_special
3. Queue self-IPI from irq_work causing recursion into irq_exit

How to detect it

Inspect system logs and crash dumps for RCU or irq_exit recursion warnings; correlate with BPF tracepoint activity or container workloads; review threat actor patterns associated with similar kernel races.

What your security team should do

• Apply fixed kernel and package versions immediately due to broad ecosystem prevalence
• Disable or audit BPF programs on tick tracepoints until patched
• Monitor for kernel lockups in production workloads