CVE-2025-39749

What it actually does

Data race on the per-CPU rcu_data->defer_qs_iw_pending field between rcu_read_unlock_special() and the irq-work handler rcu_preempt_deferred_qs_handler(), allowing concurrent read/write without synchronization when RCU read-side critical sections run inside interrupt-disabled regions on CONFIG_IRQ_WORK kernels.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel instability, crashes, or privilege escalation, increasing risk of container escape or host compromise in cloud and server environments; the issue affects widely used stable kernels with high downstream prevalence.

How an attack unfolds

An attacker with local code execution crafts a workload that invokes rcu_read_unlock() inside an interrupts-disabled region (for example via rt_spin_unlock or local_bh_enable paths) while the irq-work handler runs concurrently; the race on defer_qs_iw_pending can corrupt RCU state, leading to use-after-free or other memory-safety violations that are turned into privilege escalation. Similar patterns have been leveraged by actors such as VMSCAPE and in prior Container-Optimized OS kernel escalations.

How to fix it

Upgrade to a kernel containing commit 74f58f382a7c8333f8d09701aefaa25913bdbe0e or later; rebuild and reboot all affected systems; apply vendor backports for distribution kernels; disable rcutree.use_softirq where feasible as a temporary mitigation.

How to confirm the fix worked

Confirm kernel source contains the commit that wraps the defer_qs_iw_pending update with local_irq_save/restore; run KCSAN on RCU paths with strict mode; verify no KCSAN splats on rcu_preempt_deferred_qs_handler after upgrade.

Typical attack path

1. Obtain local unprivileged code execution on target Linux system
2. Trigger RCU read-side critical section inside hardirq-disabled context
3. Force concurrent execution of rcu_preempt_deferred_qs_handler via irq work
4. Exploit resulting data race to corrupt kernel RCU state or memory
5. Escalate to root or escape container

How to detect it

Search kernel logs and audit trails for KCSAN reports mentioning rcu_preempt_deferred_qs_handler or rcu_read_unlock_special; inspect crash dumps for RCU state corruption near irq_work paths; correlate with unexpected local privilege changes or container escapes on affected kernels.

• BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler
• rcu_read_unlock_special+0x175
• rcu_preempt_deferred_qs_handler+0x1e

What your security team should do

• Prioritize patching production kernels within 30 days given local exploitability and related threat-actor activity
• Inventory all systems running vulnerable stable kernels and schedule staged rollouts
• Enable kernel lockdown and seccomp filters to reduce local attack surface until patches are applied
• Monitor for similar RCU race reports in future kernel releases