CVE-2026-89953: Linux Kernel MTD Use-After-Free Vulnerability

CVE-2026-89953 Overview

CVE-2026-89953 is a memory leak vulnerability in the Linux kernel's mtdoops subsystem. The flaw resides in the Memory Technology Device (MTD) oops dumper, which retains an allocated page bitmap after the backing MTD device is unregistered. Each subsequent remove and re-add cycle of the same MTD device overwrites the stale pointer with a fresh allocation, leaking one vmalloc region per cycle. The issue only surfaces on systems where the backing MTD device can disappear and reappear while mtdoops remains loaded, so static MTD configurations are unaffected.

Critical Impact
Repeated MTD register and unregister events cause cumulative kernel memory exhaustion and open a possible double-free path at module exit.

Affected Products

Linux kernel builds with CONFIG_MTD_OOPS enabled
Systems using hot-pluggable or dynamically registered MTD backing devices
Long-lived kernels where mtdoops remains loaded across MTD device lifecycle changes

Discovery Timeline

2026-09-16 - CVE CVE-2026-89953 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89953

Vulnerability Analysis

The mtdoops driver captures kernel oops messages and writes them to an MTD partition for later retrieval. When the configured MTD device registers, mtdoops_notify_add() allocates the oops_page_used bitmap that tracks which flash pages have been written. When the backing MTD device is removed, mtdoops_notify_remove() detaches the dumper but does not free the bitmap.

If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the existing pointer. The prior vmalloc allocation becomes unreachable and leaks. Repeated remove and add cycles accumulate leaked kernel virtual memory. A secondary hazard exists at module exit: the stale pointer left after a remove event could lead to freeing the same bitmap twice.

Root Cause

The root cause is an asymmetric resource lifecycle in mtdoops_notify_add() and mtdoops_notify_remove(). The add path allocates the bitmap, but the remove path omits the corresponding free and pointer clear. This produces a memory leak on every remove and re-add sequence and creates a use-after-free window for the module unload path following a remove notification.

Attack Vector

Exploitation requires the ability to trigger MTD device unregister and re-register events while mtdoops remains loaded. This typically implies local administrative access, physical access to removable flash, or presence of hardware capable of hotplug events. The primary impact is denial of service through gradual kernel vmalloc exhaustion. The vulnerability is not remotely exploitable in typical configurations.

See the upstream fixes referenced in the kernel patch series for technical details on the corrected lifecycle handling.

Detection Methods for CVE-2026-89953

Indicators of Compromise

Growing kernel vmalloc usage visible in /proc/vmallocinfo correlated with MTD unregister and register events
Repeated mtd device add and remove messages in dmesg on systems running mtdoops
Progressive reduction in available kernel virtual address space over long uptime

Detection Strategies

Audit kernels with CONFIG_MTD_OOPS=y or mtdoops loaded as a module against the fixed commits
Monitor /proc/meminfoVmallocUsed trends on systems with hot-pluggable MTD hardware
Correlate MTD hotplug events from udev with kernel memory growth metrics

Monitoring Recommendations

Collect kernel memory telemetry through node exporters and alert on sustained VmallocUsed growth
Track loaded kernel module inventory across the fleet to identify hosts running mtdoops
Log MTD subsystem events for forensic correlation with resource consumption anomalies

How to Mitigate CVE-2026-89953

Immediate Actions Required

Apply the stable kernel updates that include the upstream fix commits for the mtdoops bitmap lifecycle
Inventory systems using mtdoops and prioritize patching hosts with hot-pluggable MTD devices
Reboot patched systems to load the corrected kernel where live patching is not available

Patch Information

The fix frees the bitmap after unregistering the dumper and flushing pending workers, then clears the pointer and page count so a later attach allocates fresh state. Clearing the pointer also prevents the module exit path from freeing the same bitmap twice after a remove event. Backports are available across multiple stable branches: 1e5cd8bc9023, 477d61d54e09, 698944132083, 8414f0e9f707, 956e7da12c11, a91ac71e67c3, d06f91a52af1, and f25c804947e0. Reference the kernel.org stable tree for commit metadata.

Workarounds

Unload the mtdoops module on systems that do not require oops capture to flash
Avoid repeated unregister and re-register cycles of the backing MTD device while mtdoops is loaded
Restrict local administrative access that can trigger MTD hotplug events until patches are applied

bash

# Check whether mtdoops is loaded and inspect vmalloc usage
lsmod | grep mtdoops
grep VmallocUsed /proc/meminfo

# Temporary mitigation: unload mtdoops if it is not required
sudo rmmod mtdoops