Description

In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:10.253Z",
  "pubdate": "2026-08-26T15:17:10.253Z",
  "executiveSummary": "The Linux kernel atmel-mci driver contains a use-after-free (UAF) vulnerability during the module removal process, specifically within the atmci_remove function.\nThe vulnerability arises from a race condition where the driver-managed workqueue (bh_work) can be scheduled by asynchronous events—such as interrupts, timers, or DMA completions—even after the removal process has initiated cleanup of the host structure.\nThis flaw allows for a potential memory corruption scenario where a workqueue item executes on a deallocated object, leading to undefined kernel behavior, system crashes, or potential escalation of privileges.\nThe issue affects systems utilizing the atmel-mci MMC controller. Exploitation requires the attacker to trigger module removal while the system concurrently generates MMC-related asynchronous events, creating a window for the kernel to access freed memory.\nThe risk is categorized as moderate to high, as it impacts system stability and kernel integrity. Remediation requires ensuring synchronization between the cleanup path and the lifecycle of pending work items.",
  "technicalDetails": "The root cause of this vulnerability is the lack of proper synchronization between the driver's teardown sequence in atmci_remove and the execution of the bh_work workqueue item.\nThe atmel-mci driver initializes &host->bh_work during the probe phase, binding it to the atmci_work_func function. Multiple asynchronous entry points—atmci_interrupt, atmci_timeout_timer, and atmci_dma_complete—are authorized to queue this work onto the system_bh_wq workqueue.\nDuring the module removal process, atmci_remove begins releasing resources, including disabling interrupts via ATMCI_IDR, deleting the timeout timer, and releasing DMA channels. However, the driver does not cancel or drain pending work items before these resources are finalized.\nThe attack flow follows a race condition pattern: 1) CPU1 receives an interrupt or completes a DMA transfer, triggering queue_work(system_bh_wq, &host->bh_work). 2) Concurrently, CPU0 executes atmci_remove, which proceeds to invoke atmci_cleanup_slot and release associated IRQ and timer resources. 3) Because the devm-managed host structure is freed automatically once atmci_remove returns, if the workqueue item was already queued or currently running, it will attempt to access the host structure that is being invalidated or has already been freed.\nThis results in a Use-After-Free (UAF) scenario where atmci_work_func executes with a dangling pointer to the 'host' object. Because the 'host' object is managed via devm_kzalloc, the kernel memory allocator considers this memory available for reuse once the devm resources are cleaned up, meaning subsequent kernel operations may write to or read from this memory, leading to unpredictable system state or control flow hijacking.\nThis vulnerability does not require network access and is local to the system environment. An attacker capable of triggering MMC device activity (e.g., via malicious peripheral insertion or I/O commands) while simultaneously triggering module removal can influence the timing of the race condition, although successful exploitation requires precise timing to hit the window between resource release and work completion."
}