CVE-2025-71200

What it actually does

The flaw permits a local process to write a clock frequency below 52 MHz to the mmc debugfs interface while the Rockchip DWC MSHC controller is in HS200 or HS400 mode, violating the controller's minimum-clock requirement and triggering CQE recovery failures, spurious TCN warnings, and link breakage.

Why it matters to the business

Systems using affected Rockchip-based storage controllers can experience sudden storage I/O stalls or kernel-level recovery attempts that degrade or halt workloads; the large number of container images carrying the vulnerable kernel increases exposure across build pipelines and runtime environments.

How an attack unfolds

An attacker with local access writes a sub-52 MHz value to /sys/kernel/debug/mmc*/clock via debugfs; the driver accepts the value without validation, the controller loses link synchronization, CQE recovery is attempted, and repeated failures produce warnings and potential denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit 59b8a1ca6df4db2ca250e9eeab74e2b0068d69e9 or later; rebuild and redeploy any container images (docker, dockerd, docker-dind, etc.) that embed the vulnerable kernel; restrict debugfs mounts or apply kernel configuration options that disable mmc clock debugfs writes where possible.

How to confirm the fix worked

Confirm the running kernel contains commit 59b8a1ca6df4db2ca250e9eeab74e2b0068d69e9; attempt the clock write on a test system and verify the operation is now rejected; inspect dmesg for absence of the previous CQE recovery and cqhci_irq warnings after the change.

Typical attack path

1. Obtain local shell on a system exposing the mmc debugfs entry
2. Identify the active mmc host operating in HS200/HS400 mode
3. Echo a frequency below 52 MHz into the clock debugfs file
4. Observe mmc CQE recovery messages and kernel warnings in dmesg
5. Repeat or combine with other actions to sustain storage disruption

How to detect it

Search kernel logs for strings indicating mmc CQE recovery, cqhci halt failures, or spurious TCN messages; correlate with processes writing to mmc clock debugfs paths; review audit logs for writes to /sys/kernel/debug/mmc*/clock.

• mmc0: running CQE recovery
• cqhci: Failed to halt
• cqhci: spurious TCN for tag
• WARNING: drivers/mmc/host/cqhci-core.c
• echo .* > /sys/kernel/debug/mmc*/clock

What your security team should do

• Prioritize kernel updates on all Rockchip-based hosts and container build pipelines
• Audit debugfs exposure and apply mount options or SELinux/AppArmor policies to limit access
• Monitor EPSS trend and re-evaluate if exploit code appears
• Test storage performance post-update to ensure HS200/HS400 modes remain stable