CVE-2026-80974

What it actually does

The Linux kernel SM501 multi-function device (MFD) driver leaks kernel heap memory because struct sm501_devdata allocated in sm501_pci_probe() and sm501_plat_probe() is never freed in sm501_pci_remove() and sm501_plat_remove(). Each bind/unbind, module unload, or device-removal cycle leaves an unreclaimed allocation. Repeated cycles can exhaust kmalloc/slab capacity and degrade or hang the kernel (availability-only; no disclosed memory corruption, privilege escalation, or remote code execution).

Why it matters to the business

Impact is confined to Linux systems that actually load the SM501 driver (typically older or embedded boards with a Silicon Motion SM501 companion chip). This is a local denial-of-service condition, not a breach or ransomware vector. EPSS is very low (~0.21%) and flat over 30 days, exploit maturity is none, the CVE is not in CISA KEV, and no ransomware or named-actor use is reported. Most enterprises will see negligible operational risk unless they run SM501 hardware that is frequently unbound. Patch on the normal kernel-update cadence; elevate only for SM501-equipped fleets.

How an attack unfolds

There is no remote or unauthenticated path. An attacker who already has local access sufficient to control the SM501 PCI/platform device lifecycle (sysfs unbind, driver unbind, module unload/reload, or hot-unplug) forces the leaky remove path. Each cycle drops another sm501_devdata allocation. Over many iterations kernel memory pressure rises until allocation failures, OOM kills, or a hang occur. No public exploit, payload, or threat-actor campaign is associated with this issue; it is a classic local resource-exhaustion leak, not an in-the-wild intrusion technique.

How to fix it

Install a Linux kernel that includes the SM501 remove-path fix (kfree of sm501_devdata in both sm501_pci_remove() and sm501_plat_remove()). Consume the update via your distribution or vendor kernel stream; no per-package versions were published with this advisory, so track distro CVE/kernel changelogs. Until patched, avoid unloading or unbinding sm501, restrict unprivileged access to module load/unload and sysfs driver unbind, and do not hot-remove SM501 devices in production. Hosts without SM501 hardware (driver never loaded) are not exposed.

How to confirm the fix worked

Confirm the running kernel changelog or source contains kfree() of the SM501 probe allocation in both PCI and platform remove functions. On a host, check whether the sm501 module is loaded and whether SM501 PCI/platform devices are present; absence means no exposure. After patching, a controlled bind/unbind should not grow unreclaimed kernel allocations attributable to sm501_devdata. Compare pre/post slab or kmemleak behavior if you have a test device. Verify the installed kernel package version matches your vendor’s fixed advisory.

Typical attack path

1. Obtain local access on a Linux host where the SM501 MFD driver is bound to PCI or platform hardware.
2. Confirm the sm501 driver is loaded and identify the corresponding PCI or platform device.
3. Repeatedly trigger device removal or driver teardown (unbind, module unload/reload, or equivalent hot-remove).
4. Each remove leaks struct sm501_devdata because kfree() is missing.
5. Continue cycling until slab/kmalloc exhaustion causes allocation failures, process kills, instability, or a hang.

How to detect it

This leak leaves no unique exploit payload, C2, or file drop. Hunt for whether SM501 teardown was cycled, not for a signature of ‘compromise.’ Review kernel logs (dmesg, journald/kern) around sm501 probe/remove, module load/unload, and OOM or slab exhaustion. Audit sysfs unbind and module operations (auditd rules on finit_module/delete_module and writes under /sys/bus/*/drivers/sm501/). Correlate repeated sm501 bind/unbind with rising kernel memory or kmemleak reports of sm501_devdata. Absence of the sm501 module and of SM501 hardware means the issue could not have been exercised. There are no network IOCs.

What your security team should do

• Inventory Linux hosts for the sm501 module and SM501 PCI/platform devices; deprioritize systems where the driver is absent.
• Patch SM501-equipped kernels through the normal vendor/distro kernel channel; do not treat this as an emergency KEV-style outage.
• Until patched, lock down CAP_SYS_MODULE and sysfs driver unbind so untrusted users cannot cycle the device.
• Do not hunt for remote exploitation or ransomware use; none is indicated (KEV false, EPSS ~0.21% and flat, exploit maturity none).
• Include this fix in the next kernel maintenance window and record residual risk as local DoS only.