CVE-2026-53152

What it actually does

This is a Linux kernel denial-of-service flaw in the Rockchip DesignWare MMC driver for very old Rockchip SoCs such as rk2928, rk3066, and rk3188. A kernel change made driver private data effectively mandatory during MMC initialization, but these older controllers did not previously allocate that private data because they do not support UHS phase handling. When the driver initializes and dereferences the missing private-data structure, the kernel can hit a NULL pointer dereference, resulting in a kernel oops, panic, boot failure, or loss of MMC/SD/eMMC storage access depending on system configuration.

Why it matters to the business

Systems built on affected older Rockchip platforms may become unstable or fail to boot after running a vulnerable kernel, especially if root storage depends on the affected MMC controller. The practical business impact is service interruption, device fleet outages, failed updates, and recovery effort for embedded, industrial, appliance, or IoT deployments using those older SoCs. Public exploit maturity is currently reported as none, EPSS is low, and it is not listed in CISA KEV, so this is primarily an availability and reliability risk rather than an active mass-exploitation concern.

How an attack unfolds

Exploitation does not resemble a typical remote intrusion path. The vulnerable condition is reached when a vulnerable Linux kernel initializes the dw_mmc-rockchip driver on affected old Rockchip controller variants that lack the expected private-data structure. An attacker would generally need the ability to cause the system to boot or load a vulnerable kernel and device-tree combination on affected hardware, or otherwise trigger initialization of the affected MMC controller. During initialization, the driver attempts to access private data that was not created for these older controllers, causing a NULL pointer dereference in kernel context. The likely result is denial of service through kernel crash, boot interruption, or storage subsystem failure.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the dw_mmc-rockchip driver, which provides private-data structures for the older controller variants. If vendor kernels are used, obtain the corrected kernel package or board-support-package update from the device, distribution, or SoC vendor. Where immediate patching is not possible, avoid deploying vulnerable kernel builds to rk2928, rk3066, and rk3188-based systems; pin known-good kernels; test kernel updates on representative hardware before fleet rollout; and maintain rollback or recovery access for embedded devices that may fail to boot.

How to confirm the fix worked

Confirm the running kernel includes the fix for the Rockchip MMC driver and that the affected board boots cleanly with MMC/eMMC/SD storage available. Validate on actual rk2928, rk3066, or rk3188 hardware where applicable, because the failure is hardware- and device-tree-dependent. Review kernel boot logs for absence of NULL pointer dereference, oops, panic, and dw_mmc-rockchip initialization failures. For build validation, inspect the kernel source or vendor patch set to ensure old Rockchip controller match data now supplies appropriate private driver data.

Typical attack path

1. Identify a device using an affected older Rockchip SoC such as rk2928, rk3066, or rk3188.
2. Ensure the device is running a vulnerable Linux kernel containing the dw_mmc-rockchip private-data regression.
3. Trigger boot or driver initialization for the affected MMC controller.
4. The driver initialization path attempts to access missing private data.
5. The kernel encounters a NULL pointer dereference, causing an oops, panic, boot failure, or MMC storage outage.

How to detect it

To determine whether this issue has already manifested, review kernel logs, boot logs, persistent journal data, serial console captures, crash dumps, and fleet health telemetry for NULL pointer dereferences or kernel panics during Rockchip MMC driver initialization. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops records, kdump vmcores, bootloader logs, watchdog reset records, and device management telemetry showing repeated boot loops after a kernel update. Focus on events mentioning dw_mmc-rockchip, mmc, NULL pointer dereference, kernel oops, panic, or failure to initialize MMC/eMMC storage on rk2928, rk3066, or rk3188 platforms. Because this is a denial-of-service regression rather than a code-execution issue, evidence will usually look like crashes, failed boots, storage initialization failures, or repeated watchdog resets rather than attacker-created files or persistence artifacts.

• dw_mmc-rockchip
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• mmc: dw_mmc-rockchip
• rk2928
• rk3066
• rk3188
• /sys/fs/pstore
• /proc/vmcore
• journalctl -k
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize remediation for embedded or appliance systems using old Rockchip SoCs where MMC/eMMC storage is required for boot or operation.
• Inventory Rockchip-based Linux devices and identify rk2928, rk3066, and rk3188 platforms running recently updated kernels.
• Block or delay rollout of vulnerable kernel versions to affected hardware until the fixed kernel is available and tested.
• Perform staged kernel upgrade testing on representative devices before production deployment.
• Ensure devices have rollback, rescue boot, serial console, or physical recovery procedures in case a vulnerable update causes boot failure.
• Monitor kernel logs and fleet telemetry for crashes or boot loops associated with dw_mmc-rockchip or NULL pointer dereference messages.