CVE-2024-43856

What it actually does

Race condition in dmam_free_coherent allows concurrent DMA allocation to reuse vaddr between the free and devres_destroy calls, resulting in duplicate devres list entries and incorrect entry removal that triggers WARN_ON in dmam_match.

Why it matters to the business

Linux systems performing DMA allocations may experience kernel warnings or instability; high ecosystem prevalence across 83,123 downstream dependents increases exposure for servers, embedded devices, and distributions.

How an attack unfolds

An attacker with local access spawns concurrent tasks that trigger dmam_free_coherent while racing to allocate the same vaddr, causing devres_destroy to free the wrong tracking entry and surface the warning or memory inconsistency; listed threat actors in 2024 zero-day campaigns and Linux kernel resource issues provide context for targeted local exploitation attempts.

How to fix it

Upgrade the Linux kernel to a fixed version containing commit fe2d246080f035e0af5793cb79067ba125e4fb63 or later stable releases; apply the ordering change that destroys the devres entry before freeing the DMA allocation.

How to confirm the fix worked

Verify the running kernel contains the fix commit or updated package; exercise dmam_free_coherent under concurrent load and confirm absence of dmam_match WARN_ON; review kernel changelog for the race fix.

Typical attack path

1. Obtain local execution on affected Linux kernel
2. Trigger DMA allocation and free paths concurrently via user-space or driver activity
3. Time allocation to reuse vaddr between dmam_free_coherent's free and devres_destroy
4. Force duplicate devres entries leading to incorrect removal and WARN_ON

How to detect it

Search kernel logs and dmesg for WARN_ON messages referencing dmam_match or dmam_free_coherent; inspect for concurrent DMA allocation patterns around the time of warnings; correlate with local process activity that uses coherent DMA.

• WARN_ON.*dmam_match
• dmam_free_coherent race
• duplicate devres vaddr

What your security team should do

• Prioritize kernel updates on all affected systems given 786 days since publication and high downstream prevalence
• Monitor for dmam_match warnings in kernel logs as an immediate indicator of exposure
• Restrict untrusted local code execution until patches are deployed
• Test DMA-heavy workloads post-upgrade to validate stability