CVE-2026-98210

What it actually does

Use-after-free in the mxcmmc MMC driver where mxcmci_remove() frees the host structure while host->watchdog (armed on DMA path) or host->datawork (armed on PIO path) can still execute afterward, dereferencing the freed object in mxcmci_watchdog() or the work handler.

Why it matters to the business

Kernel panic or potential local privilege escalation on systems using the affected MMC controller; low EPSS and no KEV status indicate limited real-world exploitation risk 17 days after disclosure, but embedded or industrial Linux devices may require prioritized patching to avoid downtime.

How an attack unfolds

An attacker with local access triggers device removal (or module unload) while a DMA or PIO transfer is in flight; the pending timer or work item then runs after the host is freed, enabling a use-after-free that can be leveraged for memory corruption and code execution.

How to fix it

Update to a kernel containing the fix that frees the IRQ first, then explicitly cancels datawork and deletes the watchdog in mxcmci_remove() before releasing the DMA channel; apply the stable or distribution-specific backport as soon as available.

How to confirm the fix worked

Confirm the presence of the cancel_work_sync() and del_timer_sync() calls (or equivalent) inside mxcmci_remove() and verify that IRQ release precedes those operations; test by hot-removing the device during active transfers and checking for absence of use-after-free reports in kmemleak or KASAN.

Typical attack path

1. Obtain local access on a system exposing the mxcmmc driver
2. Initiate an MMC/SD operation that arms the watchdog or datawork
3. Trigger concurrent removal of the MMC host or driver unload
4. Allow the stale timer/work to execute on the freed host object
5. Exploit the resulting memory corruption for privilege escalation

How to detect it

Search kernel logs for use-after-free reports referencing mxcmci_watchdog or mxcmmc datawork around device removal events; inspect dmesg or journalctl for oops traces containing the mxcmmc module during hot-unplug or driver unload operations.

What your security team should do

• Prioritize kernel updates on any embedded or automotive platforms using mxcmmc within the next maintenance window
• Monitor EPSS trend (stable at ~0.0018) and re-evaluate if new exploit code appears
• Enable KASAN or similar debug options in test environments to validate the fix
• Restrict unprivileged local access on affected systems until patched