CVE-2026-98212 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
mmc: hsq: Fix use-after-free in retry work
mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq.
Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work.
This issue was found by an in-house static analysis tool.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within the Linux kernel's MultiMediaCard (MMC) subsystem represents a critical use-after-free condition located specifically within the Host Queueing System implementation of the mmc_hsq driver module. This flaw arises from improper lifecycle management of asynchronous work structures during device removal operations. The core technical issue stems from the interaction between request scheduling mechanisms and resource deallocation processes, where pending kernel work items are not properly terminated before their associated memory structures are freed by the managed resource framework.
The specific mechanism triggering this vulnerability involves the mmc_hsq_pump_requests function, which is responsible for managing the queue of MMC requests. When a driver's request_atomic callback returns an -EBUSY error code indicating that the hardware or subsystem is currently busy and cannot accept new immediate commands, the system queues retry_work to handle the deferred processing of these requests at a later time. Currently, only the sdhci-sprd driver implements this specific request_atomic interface, making it the primary consumer affected by this logic path. The work structure itself is embedded within an mmc_hsq data structure that is allocated using managed device resources devm_alloc functions designed to automatically handle cleanup upon driver unbinding or device removal.
The fundamental flaw lies in the absence of explicit cancellation for retry_work during the driver's remove sequence. When a device is removed, the kernel initiates a series of cleanup steps where devres allocations are released and memory is returned to the system pool. However, because retry_work was never explicitly cancelled using standard workqueue APIs before this deallocation occurred, there exists a race condition window. If the scheduled work item had not yet executed by the time the driver unbinds, it remains pending in the kernel's global work queue infrastructure. Once the devm allocation is released and the mmc_hsq structure memory is freed, any subsequent execution of retry_work results in dereferencing pointers to hsq->mmc and hsq->mrq that no longer point to valid allocated memory regions.
This use-after-free condition poses significant operational risks including kernel panics, system crashes, or potential privilege escalation vulnerabilities if an attacker can influence the timing of device removals or manipulate work queue execution contexts. The dereference of freed memory leads to undefined behavior within the kernel space, potentially allowing for arbitrary code execution depending on how the freed memory is reallocated and what data it contains at the time of access. Such bugs are particularly dangerous because they occur during standard administrative operations like driver unloading rather than requiring complex exploitation chains involving user-space interactions.
The remediation strategy implemented in this fix leverages the devm_work_autocancel helper function provided by the Linux kernel's managed resource framework. This API ensures that retry_work is automatically cancelled and drained before the associated devm allocation for mmc_hsq is released. By integrating this cancellation step into the device removal lifecycle, the patch guarantees that no pending work items can execute after their underlying data structures have been freed. The timing of this intervention is critical; it occurs during the devres cleanup phase which takes place only after mmc_remove_host has already stopped the host controller and prevented any new requests from being queued or armed for execution, thereby eliminating the race condition entirely.
From a vulnerability classification perspective, this issue aligns with CWE-416 Use After Free, as it involves accessing memory that has been deallocated without proper synchronization or lifecycle management. In terms of attack vector mapping under MITRE ATT&CK techniques, while primarily a stability and reliability flaw rather than an intentional exploit path for external attackers, the underlying mechanism relates to improper resource cleanup which can be categorized under CWE-404 Improper Resource Shutdown or Release if viewed through the lens of denial-of-service potential. For developers maintaining MMC host controllers, this case serves as a critical reminder that all asynchronous work items embedded in managed resources must have their cancellation explicitly handled during driver teardown sequences to prevent dangling pointer dereferences and subsequent kernel instability.