CVE-2026-63861

What it actually does

This is a Linux kernel driver lifecycle flaw in the MediaTek SPI NAND flash controller path. The mtk-snfi driver registered an on-host NAND ECC engine during probe but failed to unregister it when probe failed partway through or when the device was removed. That can leave stale kernel state associated with a removed or partially initialized device, potentially causing resource leaks, kernel warnings, crashes, or use-after-free-style instability if the ECC engine is later referenced after the backing device state has been torn down. The issue is most relevant to systems using the affected MediaTek SPI NAND controller driver; it is not a typical remote network-exploitable vulnerability.

Why it matters to the business

The primary business risk is reliability and availability impact on Linux-based devices that use the affected MediaTek NAND hardware, especially embedded, appliance, router, IoT, or storage-backed systems. Successful triggering could cause kernel instability, device probe failures, or system crashes, which may lead to service interruption, device reboot loops, or maintenance windows for firmware/kernel updates. The current exploitation signal is low: EPSS is 0.00161, it is not listed in CISA KEV, no ransomware association is reported, and no public exploit maturity is indicated.

How an attack unfolds

An attacker would generally need local, privileged, or hardware-adjacent capability to influence device probing, driver binding/unbinding, module load/unload, hotplug-like behavior, or fault conditions during mtk-snfi probe. The attacker would trigger a path where the driver registers the on-host NAND ECC engine and then fails probe cleanup or removes the device without unregistering that engine. The stale ECC engine registration may then be referenced by later kernel code or collide with a subsequent probe, leading to kernel errors, memory/resource corruption symptoms, or denial of service. In most deployments this is more likely to be exposed through malformed platform state, unstable hardware, driver reload operations, or privileged local actions than through unauthenticated remote access.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the mtk-snfi fix adding devm-managed cleanup so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failure and device removal. If exact fixed package versions are not provided by the distribution or device vendor, track the upstream Linux kernel fix for the MediaTek SNFI driver and apply the corresponding vendor advisory update. Where immediate patching is not possible, reduce exposure by avoiding unnecessary driver bind/unbind operations, module reloads, hotplug testing, or fault-injection workflows on affected systems; restrict local administrative access; and consider disabling the affected driver only if the hardware is not required for boot or storage operation.

How to confirm the fix worked

Confirm whether the system includes and uses the affected driver by checking kernel configuration, loaded modules, device tree/platform hardware, and kernel logs for MediaTek SNFI or SPI NAND initialization. Validate remediation by confirming the running kernel package contains the fix that unregisters the on-host NAND ECC engine during probe unwind and remove-time cleanup. On test systems, perform safe driver reprobe/remove or controlled failure testing only in a non-production environment and verify that repeated bind/unbind or probe failure does not leave stale ECC registrations, kernel warnings, memory sanitizer findings, or crashes. Also verify vendor firmware or distribution package changelogs reference the mtk-snfi ECC engine unregister cleanup.

Typical attack path

1. Identify a Linux system using the MediaTek SPI NAND flash controller driver and on-host NAND ECC support.
2. Obtain local privileged access or another capability that can trigger driver probe, driver unbind/rebind, module unload/reload, device removal, or probe failure conditions.
3. Force or induce an mtk-snfi probe failure after ECC engine registration, or remove/unbind the device after registration.
4. Cause the kernel to retain stale ECC engine registration state because cleanup did not occur.
5. Trigger subsequent NAND/ECC activity, driver reprobe, or subsystem interaction that touches stale state.
6. Achieve a denial-of-service outcome such as kernel warning, crash, failed storage initialization, or device instability.

How to detect it

There are no reliable network indicators for prior exploitation because this flaw is in kernel driver cleanup behavior and is not known to be remotely exploitable. To investigate possible triggering, review kernel ring buffers, persistent journal logs, crash dumps, pstore/ramoops records, and device management audit logs for events involving MediaTek SNFI, SPI NAND probing, ECC engine registration, driver unbind/rebind, module unload/reload, kernel oops, KASAN reports, or crashes shortly after NAND driver probe failure or device removal. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k output, pstore entries under /sys/fs/pstore, crash/kdump artifacts, and audit logs showing privileged writes to sysfs driver bind/unbind paths. Because no public exploitation pattern or threat actor activity is reported, detection should focus on anomalous local privileged driver manipulation and correlated kernel instability rather than fixed attacker IOCs.

What your security team should do

• Prioritize patching for embedded or appliance systems that use MediaTek SPI NAND storage and have a history of kernel or storage-driver instability.
• Inventory Linux kernels and firmware builds that include the MediaTek mtk-snfi driver or MediaTek SPI NAND controller support.
• Request exact fixed kernel or firmware versions from the Linux distribution, appliance vendor, or board support package maintainer if not already published.
• Restrict privileged local access and operational workflows that can unbind, reload, or manipulate kernel device drivers on affected systems.
• Monitor kernel logs for NAND, ECC, mtk-snfi, driver probe, driver remove, KASAN, use-after-free, and kernel oops messages until patching is complete.
• Treat unexplained crashes during NAND initialization, driver reload, or device removal on affected hardware as potentially related and collect full kernel logs and crash dumps.