CVE-2025-71200: Linux Kernel SDHCI-DWCMSHC DoS Flaw

CVE-2025-71200 Overview

A vulnerability has been identified in the Linux kernel's MMC (MultiMediaCard) subsystem, specifically within the sdhci-of-dwcmshc driver used for Rockchip DWC MSHC controllers. The vulnerability allows illegal clock frequency reduction when operating in HS200 or HS400 timing modes, which can lead to link failure and system instability.

When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz causes the communication link to break, as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these high-speed modes. This can be triggered through the debugfs interface, leading to CQE (Command Queue Engine) recovery failures and potential system warnings.

Critical Impact
Exploitation of this vulnerability can cause MMC link failures, CQE recovery errors, and kernel warnings that may impact system stability on devices using Rockchip DWC MSHC controllers.

Affected Products

Linux kernel with sdhci-of-dwcmshc driver
Systems using Rockchip RK3588 and similar SoCs with DWC MSHC controllers
Devices operating MMC in HS200 or HS400 timing modes

Discovery Timeline

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

Technical Details for CVE-2025-71200

Vulnerability Analysis

The vulnerability exists in the sdhci-of-dwcmshc driver, which handles the Synopsis DesignWare Mobile Storage Host Controller interface for platforms like Rockchip. The driver failed to implement proper validation of clock frequency changes when the MMC interface is operating in high-speed modes (HS200 or HS400).

The HS200 and HS400 timing modes are high-performance operating modes for eMMC storage that require strict adherence to timing specifications. The Rockchip DWC MSHC controller specifically requires a minimum clock frequency of 52MHz when operating in these modes. Prior to the fix, the driver allowed clock frequency changes through the debugfs interface without validating whether the new frequency met the minimum requirements for the current timing mode.

Root Cause

The root cause is the lack of input validation in the clock configuration path of the sdhci-of-dwcmshc driver. The driver's debugfs interface allowed arbitrary clock frequency values to be written to /sys/kernel/debug/mmc0/clock without checking if the requested frequency was compatible with the current timing mode. When a frequency below 52MHz was set while operating in HS200/HS400 mode, it violated the hardware requirements, causing the communication link to fail.

Attack Vector

The attack vector requires local access to the system with sufficient privileges to write to the debugfs interface. An attacker with root access or appropriate capabilities could trigger this vulnerability by writing an invalid clock value through the debugfs filesystem.

The vulnerability manifests when a clock frequency below 52MHz is written to the debugfs clock interface while the MMC controller is operating in HS200 or HS400 mode. This causes the hardware link to break, triggering CQE recovery procedures that subsequently fail, resulting in kernel warnings and potential system instability.

As shown in the kernel logs from the CVE description, when the clock is set to 50000000 (50MHz) via echo 50000000 > /sys/kernel/debug/mmc0/clock, the system experiences CQE recovery failures, halt failures, and spurious TCN (Task Completion Notification) events, ultimately resulting in a kernel WARNING.

Detection Methods for CVE-2025-71200

Indicators of Compromise

Kernel log messages indicating mmc0: running CQE recovery followed by mmc0: cqhci: Failed to halt
WARNING messages originating from drivers/mmc/host/cqhci-core.c at the cqhci_irq function
Spurious TCN (Task Completion Notification) messages for MMC tags
System instability or storage access failures on Rockchip-based platforms

Detection Strategies

Monitor kernel logs (dmesg, /var/log/kern.log) for CQE recovery and halt failure messages from the cqhci subsystem
Implement auditd rules to track writes to /sys/kernel/debug/mmc*/clock debugfs interfaces
Monitor for unusual patterns of MMC subsystem errors that may indicate exploitation attempts
Check for unauthorized access to debugfs mount points on production systems

Monitoring Recommendations

Configure centralized logging to capture kernel warnings and MMC subsystem errors
Implement file integrity monitoring on debugfs access patterns
Set up alerts for repeated CQE recovery failures in the MMC subsystem
Monitor system stability metrics on devices using Rockchip DWC MSHC controllers

How to Mitigate CVE-2025-71200

Immediate Actions Required

Update to a patched Linux kernel version that includes the clock validation fix
Restrict access to the debugfs filesystem on production systems
Limit root access and capabilities that allow debugfs writes
Consider unmounting or disabling debugfs on production systems where it's not required

Patch Information

The vulnerability has been addressed through multiple kernel commits that add validation to prevent illegal clock reduction in HS200/HS400 modes. The fix adds a check to ensure clock frequencies below 52MHz are rejected when the controller is operating in these high-speed timing modes.

Patches are available from the following kernel git commits:

Workarounds

Unmount or restrict access to debugfs on production systems where clock manipulation is not needed
Implement strict access controls limiting root access on affected systems
Use SELinux or AppArmor policies to restrict writes to MMC debugfs interfaces
Monitor and alert on any attempts to modify MMC clock settings through debugfs

bash

# Configuration example - Restrict debugfs access
# Unmount debugfs on production systems
umount /sys/kernel/debug

# Or restrict access via permissions (if debugfs must remain mounted)
chmod 700 /sys/kernel/debug
chmod 700 /sys/kernel/debug/mmc*

# Example SELinux policy to deny writes to mmc debugfs
# semodule -i mmc_debugfs_deny.pp