CVE-2023-52708

What it actually does

Incorrect error handling in mmc_spi_probe causes mmc_remove_host to be invoked on a device that was never successfully added by mmc_add_host, resulting in a null pointer dereference.

Why it matters to the business

Systems using MMC-over-SPI may experience kernel crashes or denial of service during driver initialization under failure conditions, requiring reboots and potentially disrupting storage access on embedded or IoT devices.

How an attack unfolds

An attacker with the ability to influence MMC SPI device registration or induce mmc_add_host failure (for example through resource exhaustion or misconfiguration) can trigger the probe error path, leading to the null dereference during cleanup.

How to fix it

Update the Linux kernel to a version containing commit e9b488d60f51ae312006e224e03a30a151c28bdd which corrects the label flow so that mmc_remove_host is skipped on mmc_add_host failure.

How to confirm the fix worked

Verify the presence of the fix commit in the kernel source or confirm that mmc_spi_probe no longer calls mmc_remove_host after a failed mmc_add_host; test probe failure injection to ensure no dereference occurs.

Typical attack path

1. Load or trigger mmc_spi module probe on a system where mmc_add_host can be made to fail
2. Force mmc_add_host to return an error
3. mmc_spi_probe executes the buggy error path calling mmc_remove_host on unadded device
4. Null pointer dereference occurs causing kernel panic

How to detect it

Review kernel logs for oops or panic entries involving mmc_spi_probe, mmc_add_host, or mmc_remove_host around device initialization times; examine dmesg or syslog for null pointer dereference stack traces in the MMC subsystem.

What your security team should do

• Prioritize kernel updates on all systems using MMC SPI interfaces
• Monitor for kernel oops or panic logs referencing mmc_remove_host or mmc_spi during boot or module load
• Apply the fix commit or equivalent stable backport immediately on affected branches