CVE-2025-71200: mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode
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 cqhciirq+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 blkmqrunworkfn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhciirq+0x254/0x818 lr : cqhciirq+0x254/0x818 ...
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are affected in practice?
Systems using the Rockchip DWC MSHC controller in HS200 or HS400 timing modes are exposed if their MMC clock can be reduced below 52 MHz through debugfs. The documented trigger uses the mmc clock debugfs control for mmc0.
What access is required to trigger the issue?
An attacker needs local access with sufficient privileges to write to the MMC debugfs clock control. No user interaction is required.
What can be done before the patch is installed?
Avoid reducing the MMC clock below 52 MHz while the controller operates in HS200 or HS400 mode. Applying the available patch adds a check intended to prevent this invalid debugfs clock setting.
How can I identify a potentially affected system or event?
Review whether debugfs has been used to set an MMC clock below 52 MHz on a Rockchip DWC MSHC controller operating in HS200 or HS400 mode. Relevant signs include link failure, CQE recovery, failure to halt, spurious TCN messages, and warnings from cqhci_irq.