CVE-2026-89440

What it actually does

Use-after-free in the Linux kernel VIA SDMMC host driver (via-sdmmc). On probe failure after request_irq() registers the card-detect interrupt, the error path historically unmapped MMIO and returned while leaving the IRQ and carddet workqueue live. via_sdc_isr() then dereferences a freed sdhost and its MMIO base and queues carddet_work; via_sdc_card_detect() follows container_of() into that freed object and can re-enable device interrupts via via_reset_pcictrl(). Result is kernel heap UAF with high impact on confidentiality, integrity, and availability (local privilege escalation, memory corruption, or panic).

Why it matters to the business

Linux systems that load via-sdmmc (VIA SD/MMC host hardware) can be crashed or fully compromised by a local low-privilege user or already-present malware, causing outage and loss of host integrity. CVSS is high (7.8) but attack vector is local. EPSS is very low and flat (0.0017 over 30 days), exploit maturity is none, and the CVE is not in CISA KEV and is not associated with ransomware, so internet-wide mass exploitation is unlikely. Treat as a standard high-severity kernel defect: patch hosts that actually use this driver on a normal kernel-update cycle, faster on multi-user or untrusted-local-user machines.

How an attack unfolds

An attacker who already has local low-privilege code execution on a host whose VIA SDMMC controller is bound to via-sdmmc must cause probe to fail after the card-detect IRQ is registered and mmc_add_host() fails, so the host object is freed while the handler remains installed. Later card-detect interrupts run via_sdc_isr() and via_sdc_card_detect() against freed memory; the work item may also restore PCIINTCTRL. Reuse of the freed allocation can corrupt kernel objects, yielding a panic or privilege escalation to kernel/root. No public exploit, named threat actor, or ransomware campaign is tied to this issue; successful abuse depends on local access, the failing-probe race, and kernel heap layout.

How to fix it

Install a Linux kernel that includes the via-sdmmc probe-error path: disable and free the card-detect IRQ, cancel carddet_work, then re-mask the device interrupt (PCIINTCTRL) after cancel so via_reset_pcictrl() cannot leave the IRQ live, before unmapping registers. Use your distribution or OEM kernel package once that change is present; rebuild custom kernels from a tree that contains “mmc: via-sdmmc: stop card-detect handling on probe failure.” Reboot onto the patched kernel. If an update is delayed, blacklist the via-sdmmc module on systems that do not need VIA SD/MMC, and limit untrusted local users. Exact distro package versions were not supplied with this record—track vendor advisories for the build that contains this fix.

How to confirm the fix worked

Confirm the running kernel (uname -r plus distro changelog, RPM/DEB/advisory notes, or kernel git history) includes the via-sdmmc probe-failure IRQ teardown. Verify whether via-sdmmc is loaded (lsmod) and whether VIA SD/MMC PCI functions are bound to that driver. After patching and reboot, failed probe/unbind should not leave a card-detect IRQ or carddet work queued against a freed host. Review post-patch dmesg for absence of via-sdmmc oops on bind failure. Do not run privilege-escalation or heap-spray tests on production hosts.

Typical attack path

1. Obtain local low-privilege execution on a Linux host that loads the via-sdmmc driver
2. Cause via-sdmmc probe to fail after card-detect IRQ registration so the host is freed while the ISR remains registered
3. Trigger the dangling card-detect interrupt and/or carddet workqueue against the freed host and MMIO
4. Corrupt reused kernel heap objects via the UAF in via_sdc_isr / via_sdc_card_detect
5. Crash the kernel or escalate to kernel/root privileges

How to detect it

There is no known in-the-wild exploit and no network beacon; hunt kernel crash evidence, not C2. Search dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore, pstore, and KASAN reports for Oops/BUG/use-after-free frames in via_sdc_isr, via_sdc_card_detect, via_reset_pcictrl, or the via-sdmmc module, especially around probe failure or mmc_add_host errors and unexpected card-detect work after a failed bind. Correlate timestamps with via-sdmmc module load/unload and PCI SD host bind attempts. Lack of those frames does not prove the host was never attacked by other means, but they are the primary artifacts for this defect.

• via_sdc_isr
• via_sdc_card_detect
• via_reset_pcictrl
• via-sdmmc
• via_sdmmc
• KASAN: use-after-free
• Unable to handle kernel paging request
• Oops: .*via_sdc

What your security team should do

• Inventory Linux hosts that load via-sdmmc or enumerate VIA SD/MMC controllers and patch-and-reboot those first
• Apply vendor/distribution kernel updates containing the via-sdmmc probe-error IRQ teardown; there is no KEV due date and EPSS is low, so this is a scheduled high-severity kernel fix except on multi-tenant or untrusted-local-user systems
• Blacklist via-sdmmc where the hardware is unused as a temporary mitigation
• Keep kernel oops, kdump/vmcore, and pstore collection enabled so any pre-patch crash in this driver is captured
• Watch distro kernel advisories for the exact package versions that ship this mmc via-sdmmc change