CVE-2026-89441: mmc: via-sdmmc: cancel card-detect work on remove
In the Linux kernel, the following vulnerability has been resolved:
mmc: via-sdmmc: cancel card-detect work on remove
Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddetwork already queued by the handler can still run after viasdremove() returns. viasdccarddetect() recovers the host through containerof() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory.
Cancel carddetwork after freeing the IRQ and before cancelling finishbhwork, which the card-detect handler can also queue. carddetwork can re-enable the interrupt through viaresetpcictrl(); mask it again afterwards.
This issue was found by an in-house static analysis tool and confirmed by manual code review.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In mmc: via-sdmmc, on device remove: cancel card-detect work (carddet_work) after freeing the IRQ and before cancelling remaining teardown work, to prevent queued card-detect work from running after via_sd_remove() returns and touching freed memory.
Linux kernel (mmc: via-sdmmc) cancel card-detect work ordering on remove = Cancel carddet_work after freeing the IRQ and before cancelling/tearing down (on remove) - Operational
Ensure the device interrupt is disabled and the IRQ is freed before cancelling carddet_work on remove, so that no new card-detect interrupts can queue additional work after teardown begins.
Event History
Frequently Asked Questions
When can the use-after-free occur?
It can occur during device removal if card-detect work was already queued by the interrupt handler before the IRQ was disabled and freed. That queued work may run after the remove function returns and access host memory or MMIO state that has been freed.
What condition is needed for exploitation or triggering?
The affected driver must have queued card-detect work before removal begins. The description does not identify any remote attack path or additional attacker-controlled prerequisite.
What is the mitigation if an update cannot be applied immediately?
The provided information does not specify an operational workaround. The documented fix cancels queued card-detect work after freeing the IRQ, before cancelling finish_bh_work, and masks the interrupt again because card-detect work can re-enable it.