CVE-2026-45921

What it actually does

This vulnerability is a local denial-of-service issue in the Linux kernel MTD partition parser for TP-Link safeloader images. The vulnerable function allocates a temporary buffer while parsing the safeloader partition table, but on a specific allocation-failure path it frees other parser state without freeing that buffer. A local attacker who can cause the parser to repeatedly process affected MTD/safeloader data, especially under memory pressure, may be able to leak kernel memory over time and degrade system availability. The issue does not provide confidentiality or integrity impact based on the published details.

Why it matters to the business

Systems using affected Linux kernel builds, particularly embedded Linux devices or appliances that rely on MTD flash partition parsing, may become unstable or unavailable if kernel memory is exhausted. The practical risk is lower than remotely exploitable vulnerabilities because exploitation requires local access and a specific kernel code path, but availability-sensitive devices may still be affected. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so remediation should be handled through normal kernel update cycles unless the affected parser is exposed in a high-reliability or multi-user environment.

How an attack unfolds

An attacker first needs local access with the ability to influence or repeatedly trigger parsing of TP-Link safeloader MTD partition data on a vulnerable kernel. The attacker then induces the parser to enter the error path where allocation of a partition name fails after the temporary parsing buffer has already been allocated. Because the vulnerable kernel fails to release that buffer on this error path, each successful trigger can leak kernel memory. Repeated triggering may progressively consume available memory until the system becomes slow, unstable, kills processes, or requires reboot. There is no indication from the advisory that this flaw enables code execution, privilege escalation, data theft, or remote exploitation by itself.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or device vendor that includes the fix for the MTD TP-Link safeloader parser memory leak. Because no exact fixed package versions were provided, track the vendor kernel advisory or upstream stable kernel notes for the commit that frees the temporary buffer in the err_free path of mtd_parser_tplink_safeloader_parse(). For embedded products, update firmware images that bundle the corrected kernel. If immediate patching is not possible, reduce exposure by limiting local shell or administrative access, disabling unnecessary MTD parser functionality where feasible, restricting access to flash/MTD device interfaces, and monitoring systems for abnormal memory growth or repeated MTD parser failures.

How to confirm the fix worked

Confirm the running kernel package or firmware build includes the vendor fix for the MTD TP-Link safeloader parser. Review kernel source or vendor patch notes for a change that frees the temporary buffer buf in the err_free error path in mtd_parser_tplink_safeloader_parse(). On Linux systems, verify the active kernel version after reboot using uname -a and compare it with the vendor-fixed kernel or firmware release. For custom kernels, inspect the relevant source under the MTD parser implementation and confirm the error handler releases buf before returning. Operationally, validate that repeated parser failure conditions no longer cause unbounded memory growth in a controlled test environment.

Typical attack path

1. Obtain local access to a system running an affected Linux kernel with the TP-Link safeloader MTD parser reachable.
2. Identify a way to cause the kernel to parse safeloader-formatted MTD partition data, such as by interacting with device, flash, or parser-related workflows available on the system.
3. Apply memory pressure or provide crafted parser input that causes allocation of parts[idx].name to fail after the temporary buffer has been allocated.
4. Repeat the trigger so the kernel leaks memory on each failed parse path.
5. Continue until available memory is depleted enough to cause degraded performance, process failures, service disruption, or system reboot.

How to detect it

Look for evidence of repeated MTD partition parser failures followed by memory pressure, OOM-killer activity, watchdog resets, or unexpected reboots. Useful log sources include kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, embedded device syslog, crash dumps, and firmware management logs. Focus on repeated messages involving MTD, partition parsing, TP-Link safeloader parsing, allocation failures, and out-of-memory conditions occurring close together. There are no public reports of exploitation, no known threat actors, and no known network indicators for this issue; detection should therefore be behavioral and host-focused rather than signature-only.

• mtd_parser_tplink_safeloader_parse
• tplink_safeloader
• tplink-safeloader
• MTD
• mtd:
• partition parser
• Out of memory
• oom-killer
• Memory allocation failure
• page allocation failure
• Kernel panic - not syncing
• watchdog: watchdog0: watchdog did not stop

What your security team should do

• Inventory Linux and embedded Linux assets that use MTD flash parsing or vendor firmware based on affected Linux kernel versions.
• Prioritize patching for embedded appliances, routers, network devices, industrial devices, and other availability-sensitive systems where local users or management interfaces could trigger MTD parsing paths.
• Apply vendor kernel or firmware updates that include the memory-leak fix, then reboot into the corrected kernel where required.
• Restrict local access to systems until patched, especially access to flash, MTD, firmware-update, or low-level device interfaces.
• Monitor for repeated kernel MTD parser errors, unexplained memory depletion, OOM events, watchdog resets, or device reboots.
• Because this is not KEV-listed, not ransomware-associated, and has very low EPSS, handle through standard vulnerability management unless the affected device class has high availability requirements.