CVE-2025-71221: Linux Kernel Race Condition Vulnerability

CVE-2025-71221 Overview

A race condition vulnerability has been identified in the Linux kernel's DMA engine subsystem, specifically within the mmp_pdma_residue() function of the MMP PDMA (Platform DMA) driver. This vulnerability allows for a use-after-free condition when accessing descriptor lists and their contents due to improper synchronization between concurrent operations.

The race condition manifests when multiple threads call tx_status() while a tasklet on another CPU is simultaneously freeing completed descriptors. Without proper locking mechanisms, one CPU may attempt to access a descriptor structure that has already been freed by another CPU, resulting in undefined behavior and potential system instability.

Critical Impact

Use-after-free vulnerability in Linux kernel DMA subsystem can lead to system crashes, kernel memory corruption, and potential privilege escalation when running DMA operations with multiple threads.

Affected Products

• Linux kernel with MMP PDMA driver enabled
• Systems using dmaengine subsystem with multi-threaded DMA operations
• Embedded systems utilizing Marvell MMP platform DMA controller

Discovery Timeline

• 2026-02-14 - CVE CVE-2025-71221 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2025-71221

Vulnerability Analysis

The vulnerability exists in the mmp_pdma_residue() function, which calculates the residual bytes remaining in a DMA transfer. The function iterates through a linked list of software descriptors (chain_running) without holding the appropriate spinlock (desc_lock), creating a window for race conditions with the interrupt handler's tasklet.

The fundamental issue is a Time-of-Check Time-of-Use (TOCTOU) race condition combined with improper resource lifecycle management. When DMA transfers complete, the interrupt handler's tasklet acquires desc_lock, moves completed descriptors, and frees them to the DMA pool. Simultaneously, if another thread is traversing the descriptor list in mmp_pdma_residue() without holding the lock, it may dereference a pointer to memory that has been freed.

This issue is reproducible when running the kernel's dmatest module on the same DMA channel with the threads_per_chan parameter set greater than 1, indicating that multi-threaded DMA operations are required to trigger the race.

Root Cause

The root cause is missing synchronization in mmp_pdma_residue(). While the interrupt handler's tasklet properly acquires chan->desc_lock before manipulating the descriptor list and freeing descriptors, the mmp_pdma_residue() function accesses the same shared data structures without any locking protection. This violates the critical section requirements for safe concurrent access to the chain_running list and its contained descriptor structures.

Attack Vector

The race condition sequence occurs as follows:

CPU 0 (tx_status path):

1. mmp_pdma_tx_status() is called to check transfer status
2. mmp_pdma_residue() is invoked without acquiring desc_lock
3. The function begins iterating through chain_running list via list_for_each_entry()

CPU 1 (Interrupt handler path):

1. DMA interrupt fires, triggering dma_do_tasklet()
2. Tasklet acquires spin_lock(&desc_lock)
3. Completed descriptor is moved via list_move(sw->node, ...)
4. Tasklet releases spinlock and calls dma_pool_free(sw) to free the descriptor

Exploitation:
Back on CPU 0, when the iteration continues and attempts to access sw->desc, the memory has already been freed, resulting in a use-after-free condition. An attacker with local access who can control DMA operations could potentially exploit this to corrupt kernel memory or achieve privilege escalation.

Detection Methods for CVE-2025-71221

Indicators of Compromise

• Kernel panic or oops messages referencing mmp_pdma_residue or mmp_pdma_tx_status functions
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in DMA engine code
• System instability during multi-threaded DMA operations on MMP platforms
• Unexpected kernel crashes when using dmatest module with multiple threads per channel

Detection Strategies

• Enable KASAN in kernel build configuration to detect use-after-free conditions at runtime
• Monitor kernel logs for DMA-related warnings or stack traces involving mmp_pdma functions
• Deploy kernel lockdep debugging to identify potential locking violations in DMA drivers
• Use ftrace or perf to trace mmp_pdma_residue() calls and correlate with system crashes

Monitoring Recommendations

• Implement continuous monitoring of kernel ring buffer (dmesg) for DMA subsystem errors
• Enable kernel crash dump collection to capture memory state during race condition triggers
• Monitor system stability metrics during DMA-intensive workloads on affected platforms
• Set up alerts for abnormal kernel memory allocation patterns in the DMA pool subsystem

How to Mitigate CVE-2025-71221

Immediate Actions Required

• Apply the kernel patches from the official stable kernel tree immediately
• If patching is not immediately possible, avoid using multi-threaded DMA operations (threads_per_chan > 1)
• Disable the mmp_pdma driver module if not required for system operation
• Monitor affected systems for signs of exploitation or system instability

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability by adding proper spinlock protection around the chain_running list iteration and descriptor access in mmp_pdma_residue().

The fix involves acquiring chan->desc_lock before iterating through the descriptor list and releasing it after all accesses to shared descriptor data are complete. This ensures mutual exclusion with the interrupt handler's tasklet that frees completed descriptors.

Official patches are available through the kernel stable tree:

• Kernel Git Commit 9f665b3
• Kernel Git Commit a143545

Workarounds

• Configure dmatest module to use single-threaded operation per channel (threads_per_chan=1)
• Blacklist the mmp_pdma module if alternative DMA drivers are available for your platform
• Implement rate limiting on DMA operations to reduce the probability of race condition occurrence
• Consider disabling the affected DMA channel until patches can be applied

# Configuration example
# Blacklist mmp_pdma driver if not required
echo "blacklist mmp_pdma" >> /etc/modprobe.d/blacklist.conf

# Alternatively, limit dmatest to single thread per channel
modprobe dmatest threads_per_chan=1 iterations=1000

# Verify driver is not loaded
lsmod | grep mmp_pdma