CVE-2026-98210: mmc: mxcmmc: cancel data work and watchdog on remove
In the Linux kernel, the following vulnerability has been resolved:
mmc: mxcmmc: cancel data work and watchdog on remove
mxcmciremove() frees the host through the devm tail, but neither it nor mmcremovehost() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmcisetupdata(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmciwatchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either.
Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmciremove(), before dmareleasechannel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In mxcmci_remove(), free the devm-registered IRQ first, then cancel host->datawork and delete host->watchdog before dma_release_channel(); this prevents trailing IRQ or watchdog handlers from accessing the freed host or re-arming datawork.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's mxcmmc MMC driver are affected when the driver is removed while its DMA watchdog timer or PIO data work may still be pending. The issue concerns asynchronous driver state that can outlive the host object during removal.
What condition triggers the unsafe behavior?
A driver removal must occur after the DMA path has armed the 10-second watchdog or the IRQ handler has scheduled PIO data work, but before those callbacks have completed or been drained. A pending callback can then run after the host has been freed and dereference it.
How can I determine whether a kernel contains the fix?
Inspect mxcmci_remove() for removal logic that frees the devm-registered IRQ first, then cancels datawork and deletes the watchdog before dma_release_channel(). The provided stable references identify commits containing the resolution.