CVE-2026-89441

What it actually does

A use-after-free in the Linux kernel VIA SD/MMC host driver (via-sdmmc) allows a previously queued card-detect work item to run after device removal has freed the host object. The leftover work recovers the host via container_of() and dereferences its MMIO base, touching freed kernel memory. Disabling the interrupt and freeing the IRQ stops new work from being queued but does not cancel work already scheduled, so remove-path teardown can race with carddet_work (which can also re-enable the interrupt).

Why it matters to the business

On hosts that use VIA SD/MMC controllers, a local user could crash the kernel or, if they win the race and corrupt kernel heap, potentially gain higher privileges and disrupt availability of storage/card I/O. The issue is not in CISA KEV, is not associated with ransomware, has no known public exploit, and EPSS remains very low and flat (~0.175% over 30 days), so widespread opportunistic exploitation is unlikely. Risk is concentrated on remaining VIA SDMMC hardware; patch promptly on those systems because kernel memory corruption still carries high impact if reached.

How an attack unfolds

A local, low-privileged user on a system with the via-sdmmc driver loaded would try to force driver teardown (unbind/remove of the SD/MMC host) while a card-detect interrupt has already queued carddet_work. If that work runs after via_sd_remove() returns, it operates on a freed host structure and can corrupt kernel memory. There are no named threat actors, KEV listings, or public exploits associated with this CVE; exploitation would be local, timing-sensitive, and hardware-specific rather than a remote wormable attack.

How to fix it

Apply a Linux kernel update that includes the via-sdmmc fix to cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, and to re-mask the interrupt if carddet_work re-enabled it via via_reset_pcictrl(). Prefer the vendor or distro kernel that ships this change; if you build in-tree, take the stable commit that implements that cancel/mask ordering. There is no complete configuration workaround that eliminates the race on affected VIA SDMMC hardware other than not loading via-sdmmc or removing the device before unpatched kernels run the old remove path. Reboot onto the patched kernel so the updated driver is active.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory includes “mmc: via-sdmmc: cancel card-detect work on remove.” Check whether via-sdmmc is loaded (lsmod / /proc/modules) and whether VIA SD/MMC PCI devices are present. After upgrade, verify the module or vmlinux contains the post-IRQ cancel of carddet_work and the subsequent interrupt remask, then reboot and re-check module/kernel version. Unpatched exposure is limited to kernels still shipping the old via_sd_remove() ordering.

Typical attack path

1. Obtain local unprivileged access on a Linux system whose MMC stack uses the via-sdmmc host driver
2. Cause card-detect activity so the interrupt handler queues carddet_work
3. Trigger device removal or driver unbind so via_sd_remove() frees the IRQ and host while that work may still be pending
4. Win the race so carddet_work (and possibly finish_bh_work it can queue) runs against the already-freed host/MMIO mapping
5. Use the resulting kernel use-after-free for denial of service or, if heap corruption is controlled, local privilege escalation

How to detect it

This is a local race on driver removal, so look for kernel faults around via-sdmmc teardown rather than network beacons. Review kernel logs (journald/kern.log/dmesg, crash dumps, kdump/vmcore) for oops/BUG/page-fault or KASAN use-after-free traces naming via_sdmmc, via_sd_remove, via_sdc_card_detect, carddet_work, or via_reset_pcictrl, especially paired with device unbind/remove or MMC card-detect storms. Check whether unprivileged users recently triggered driver unbind, device deletion, or rapid card insert/remove. No public exploit tooling or named actor TTPs are documented; absence of these logs does not prove the bug was never hit if the box simply panicked and rebooted.

• via_sdmmc
• via_sd_remove
• via_sdc_card_detect
• carddet_work
• via_reset_pcictrl
• finish_bh_work
• KASAN: use-after-free
• Unable to handle kernel paging request
• Oops: 0000 [#1]

What your security team should do

• Inventory Linux hosts for VIA SD/MMC hardware and a loaded via-sdmmc module; patch and reboot those first
• Roll the kernel update through standard distro channels even on fleets without VIA SDMMC, to stay aligned with stable trees
• Treat as a standard local kernel UAF (CVSS 7.8, AV:L, PR:L): prioritize multi-tenant, developer, and untrusted-local-user systems over isolated appliances
• Do not wait on KEV or EPSS: neither indicates active exploitation, but kernel UAFs should still be closed on a normal patch cycle
• Watch vendor/stable kernel notes for the exact package version your distribution maps this commit to