CVE-2026-93049 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
mtd: mtdswap: Avoid freeing registered blktrans device twice
In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice.
add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev.
The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice.
This issue was found by a static analysis checker and confirmed by manual source review.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's MTD swap subsystem contains a double-free vulnerability within its device initialization error handling path, specifically in the mtdswap_add_mtd function. This flaw arises from an improper sequence of cleanup operations when debugfs setup fails after the block layer translation device has already been successfully registered. The core issue lies in the interaction between the kernel's block layer infrastructure and the MTD subsystem's internal state management, where a failure to create necessary filesystem entries triggers a cascade of deallocation calls that target the same memory object more than once. This type of error is classified under CWE-415 Double Free, which occurs when an application frees a region of memory twice without ensuring it has been reallocated between the two free operations. Such vulnerabilities can lead to heap corruption, kernel panics, or potentially exploitable conditions depending on how the allocator handles the double-free event and what data structures reside in adjacent memory regions at that moment.
The technical mechanism behind this vulnerability involves the lifecycle management of mtd_blktrans_dev structures. When add_mtd_blktrans_dev() is invoked, it initializes a reference to the block layer translation device and publishes the associated disk structure to the system. If subsequent operations succeed, the device functions normally; however, if debugfs setup fails immediately after registration, the error handling logic must unwind these changes safely. The code correctly calls del_mtd_blktrans_dev() to tear down the disk and drop the reference count held by the block layer infrastructure. Once this reference count reaches zero, blktrans_dev_release() is triggered internally to free the mtd_blktrans_dev structure itself. However, the error path in mtdswap_add_mtd does not account for this automatic deallocation. Instead of clearing the local pointer variable after deregistration, it falls through to a common cleanup label that explicitly calls kfree on the same mbd_dev pointer. This results in attempting to free memory that has already been returned to the kernel's slab allocator by blktrans_dev_release(), creating a double-free condition.
The operational impact of this vulnerability is primarily stability-related for systems utilizing MTD swap functionality, which is common in embedded Linux environments and devices with flash-based storage where traditional block devices are not available or practical. A successful exploitation could lead to a kernel oops or panic due to heap corruption caused by the double free. While static analysis tools identified this issue through code review patterns typical of resource management errors, manual verification confirmed that the logic flaw is deterministic in failure scenarios involving debugfs initialization. The risk level varies based on system configuration; since MTD swap requires specific hardware support and kernel configurations, it may not be present in all deployments. Nevertheless, for affected systems, this represents a significant reliability issue that can cause denial of service through system crashes during device registration phases, particularly if triggered by local users with the ability to load or configure MTD modules under constrained conditions.
Mitigation strategies focus on correcting the error handling logic within the mtdswap_add_mtd function. The primary fix involves setting the local pointer variable for the blktrans device structure to NULL immediately after calling del_mtd_blktrans_dev(). This ensures that when execution proceeds to the common cleanup label, any subsequent kfree calls targeting this pointer will operate on a null value or be skipped entirely if guarded by appropriate checks, thereby preventing the double free. Developers should also review similar patterns in other MTD subsystem components where registration and error handling intersect with kernel reference counting mechanisms. From a broader security perspective, this incident highlights the importance of rigorous static analysis integration into development workflows to catch resource management errors early. Adhering to secure coding practices that explicitly manage ownership semantics—clearly defining which function is responsible for freeing allocated memory—is critical in complex subsystems like MTD where multiple layers interact with shared data structures.