CVE-2025-71200 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode
When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz will lead to link broken as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these modes.
Add a check to prevent illegal clock reduction through debugfs:
root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0: running CQE recovery
mmc0: cqhci: Failed to halt mmc0: cqhci: spurious TCN for tag 0 WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24 Modules linked in: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blk_mq_run_work_fn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhci_irq+0x254/0x818 lr : cqhci_irq+0x254/0x818 ...
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/06/2026
The vulnerability CVE-2025-71200 affects the Linux kernel's mmc subsystem, specifically within the sdhci-of-dwcmshc driver that manages the Rockchip DWC MSHC controller. This issue represents a critical timing constraint violation that occurs when operating in high-speed modes HS200 and HS400, where the controller requires maintaining a minimum clock frequency of 52MHz to ensure link integrity. The flaw stems from insufficient validation mechanisms that allow illegal clock reduction operations through the debugfs interface, creating a scenario where system stability is compromised when the clock frequency drops below the required threshold.
The technical implementation of this vulnerability manifests through improper bounds checking in the clock management subsystem. When a user or process attempts to set a clock frequency below 52MHz via debugfs interface at /sys/kernel/debug/mmc0/clock, the system fails to validate whether the requested frequency is compatible with the current HS200 or HS400 operating mode. This validation failure leads to a cascade of errors including CQE (Command Queue Engine) recovery attempts, cqhci (Command Queue Host Interface) halting failures, and spurious TCN (Transfer Complete Notification) events that indicate system-level communication breakdowns. The kernel logs demonstrate that such operations trigger immediate system instability, with the kworker thread encountering critical failures in the cqhci_irq function at offset 0x254, indicating direct hardware interface corruption.
This vulnerability directly impacts system reliability and operational security by creating potential denial-of-service conditions and data integrity risks during high-speed storage operations. The Rockchip DWC MSHC controller's requirement for maintaining minimum clock frequencies in HS200/HS400 modes stems from the physical limitations of the hardware's signal integrity requirements, where frequencies below 52MHz cannot maintain proper electrical characteristics for reliable data transfer. The operational impact extends beyond simple performance degradation to include complete system instability, particularly in embedded systems and mobile platforms where such controllers are prevalent, affecting devices ranging from single-board computers to automotive infotainment systems.
The mitigation strategy for this vulnerability involves implementing proper frequency validation checks within the debugfs interface to prevent illegal clock reduction operations. The fix should enforce minimum frequency constraints based on current operating modes, specifically ensuring that HS200 and HS400 modes maintain frequencies above 52MHz. This approach aligns with CWE-126 (Buffer Over-read) and CWE-129 (Improper Validation of Array Index) categories, as the vulnerability stems from inadequate input validation and boundary checking. Additionally, the solution should integrate with established security frameworks such as the ATT&CK technique T1059.001 (Command and Scripting Interpreter: PowerShell) through proper input sanitization, preventing malicious actors from exploiting this weakness to disrupt system operations. The fix must also consider the broader context of device driver security and implement proper access controls around debugfs interfaces to prevent unauthorized modification of critical hardware parameters that could lead to system instability or data corruption.