CVE-2026-98210 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
mmc: mxcmmc: cancel data work and watchdog on remove
mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), 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 mxcmci_watchdog(). 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 mxcmci_remove(), before dma_release_channel(). 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel driver for Freescale i.MX Multimedia Card Interface (mxcmci) contains a resource management flaw that leads to use-after-free conditions during device removal. This vulnerability arises from improper handling of asynchronous state when the driver is unloaded or the hardware is removed. Specifically, the mxcmci_remove function relies on managed resources devm for freeing the host structure but fails to explicitly drain the drivers own asynchronous work items and timers before this deallocation occurs. The core issue involves two distinct mechanisms: a watchdog timer used in DMA-based data transfers and a delayed work struct used in Programmed I/O PIO paths. Both of these components can execute code that references the now-freed host structure, leading to kernel crashes or potential exploitation scenarios where an attacker might influence memory contents through race conditions during device removal.
The technical flaw centers on the mxcmci_setup_data function which arms a watchdog timer for ten seconds when DMA transfers are initiated. This timer is intended to handle timeouts if the transfer does not complete within the expected timeframe. However, under normal operation this timer is only cancelled in the DMA completion and interrupt handler paths. When the device is removed via mxcmci_remove, these completion handlers are never invoked because no new transactions are started. Consequently, if a transaction was ongoing or recently completed when removal began, the watchdog timer may still be armed. If it fires after the host structure has been freed by devm cleanup routines, the callback function mxcmci_watchdog will attempt to dereference invalid memory addresses within the host structure. This constitutes a classic use-after-free vulnerability where kernel code accesses memory that is no longer validly allocated for its intended purpose.
Similarly, the driver utilizes a delayed work item named datawork which is scheduled from interrupt handlers when operating in PIO mode. Like the watchdog timer this asynchronous task can persist beyond the point of device removal if not explicitly cancelled. The remove path does not invoke cancel_delayed_work_sync or equivalent synchronization primitives to ensure that any pending execution contexts are completed before proceeding with resource deallocation. This oversight means that an IRQ handler could schedule work items just as the driver is being unloaded, leading to race conditions where the work item executes after the host structure has been unmapped and freed. The combination of these two asynchronous mechanisms creates multiple vectors for instability during hotplug events or module unloading operations.
The operational impact of this vulnerability includes kernel panics resulting in system crashes denial of service particularly on embedded systems using i.MX SoCs where MMC controllers are frequently added and removed via SD card insertion removal or USB attached storage devices. In more severe scenarios an attacker with local access who can trigger device removal while active transfers are occurring might exploit the use-after-free condition to achieve arbitrary code execution if they can control the memory layout such that freed host structure space is reallocated for malicious purposes. The vulnerability was identified through static analysis indicating it likely exists in production kernels and affects systems relying on stable driver behavior during dynamic configuration changes.
Mitigation requires modifying the mxcmci_remove function to properly synchronize with asynchronous operations before freeing resources. The correct sequence involves first releasing the IRQ line using devm_free_irq or equivalent managed resource functions to prevent new interrupts from re-arming work items or timers. Following this cancellation of any pending delayed work via cancel_delayed_work_sync ensures that PIO path tasks are completed and will not execute post-freeing. Deletion of the watchdog timer through del_timer_sync guarantees that DMA timeout handlers do not fire after host deallocation. These steps must occur before calling dma_release_channel to ensure all hardware state is quiesced. This approach aligns with standard kernel programming practices for managing asynchronous callbacks in device drivers ensuring that no dangling references remain when memory is returned to the system allocator.
From a classification perspective this vulnerability maps to CWE-416 Use After Free which describes situations where pointers are used after they have been freed leading to undefined behavior and potential security breaches. It also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization Race Conditions specifically regarding the lack of proper synchronization between driver removal logic and asynchronous hardware completion handlers. In terms of ATT&CK framework this could be associated with T1059 Command Scripting if exploited for privilege escalation or persistence although primarily it represents a stability issue exploitable for denial of service attacks against embedded Linux systems. Developers should audit similar drivers that manage timers and work queues to ensure removal paths explicitly cancel all pending asynchronous operations before releasing host structures preventing recurrence of this class of bugs across the kernel codebase.