CVE-2024-40986

What it actually does

Race condition in xdma_channel_isr() where xdma->stop_request is accessed without acquiring the vchan lock, permitting concurrent modification during DMA operations.

Why it matters to the business

May cause kernel instability, crashes, or data corruption on systems using Xilinx DMA engines, potentially disrupting Linux-based servers, embedded devices, and workloads with low overall urgency due to absence of known exploitation or ransomware use.

How an attack unfolds

An attacker triggers concurrent DMA channel operations and interrupt service routines to race on stop_request access without the vchan lock, aiming to induce memory corruption or denial of service; no named threat actors or campaigns are associated with this issue.

How to fix it

Update the Linux kernel to include commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 or later; rebuild and deploy the fixed kernel across affected systems.

How to confirm the fix worked

Inspect the xdma_channel_isr() function in the dmaengine xilinx driver source to confirm vchan lock acquisition precedes stop_request usage; verify running kernel contains the referenced commit or equivalent fix.

Typical attack path

1. Initiate DMA transfer on Xilinx XDMA channel
2. Concurrently trigger channel stop or related operations from another context
3. Allow ISR to execute without vchan lock protection on stop_request
4. Exploit resulting race to corrupt kernel state or cause panic

How to detect it

Examine kernel logs and crash dumps for oops/panic messages referencing xdma, dmaengine, or channel ISR functions; correlate with DMA activity timestamps.

What your security team should do

• Prioritize kernel updates on systems using Xilinx DMA hardware
• Test updated kernels in staging environments before production rollout
• Review DMA-related kernel logs for signs of instability during normal operations