CVE-2025-38095

What it actually does

Race condition in dma-buf due to incorrect memory barrier placement with smp_store_mb allowing reordering of stores to num_fences before pointer updates, enabling null pointer dereference.

Why it matters to the business

Kernel crashes or local privilege escalation on Linux systems handling dma buffers can disrupt services, enable malware persistence, and require urgent patching across fleets with high downstream kernel dependents.

How an attack unfolds

Attacker triggers concurrent dma-buf fence operations on a vulnerable kernel; reordering exposes a window where num_fences is updated before the fence pointer, dereferencing null and potentially allowing controlled memory corruption for privilege escalation, as seen in related Linux kernel campaigns.

How to fix it

Update Linux kernel to commit 90eb79c4ed98a4e24a62ccf61c199ab0f680fa8f or later; for rancher-telemetry update to 0.6.2-r2 or newer on Chainguard and Wolfi builds.

How to confirm the fix worked

Verify presence of the barrier fix in dma-buf code and test concurrent fence operations under load to confirm absence of reordering-induced dereferences.

Typical attack path

1. Identify system using dma-buf interfaces
2. Craft concurrent fence add/remove operations from user space or driver context
3. Trigger memory reordering via timing or CPU migration
4. Cause null dereference and exploit resulting corruption for code execution

How to detect it

Review kernel logs for dma_buf fence related oops or null pointer dereference panics around fence update paths; correlate with process activity involving dma-buf drivers.

What your security team should do

• Prioritize kernel upgrades on all affected Linux distributions within 30 days given ecosystem prevalence
• Monitor for related privilege escalation activity from listed threat actors
• Apply compensating controls such as restricting unprivileged dma-buf access until patched