CVE-2026-93048 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()
mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior.
Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value.
With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers:
WARN_ON((!mtd->erasesize || !master->_erase) && !(mtd->flags & MTD_NO_ERASE))
in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the "out of reach" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error.
Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Memory Technology Device subsystem contains a logic flaw within the partition management code that allows for undefined behavior when processing specific offset values via ioctl interfaces. The vulnerability centers on the function mtd_add_partition, which is responsible for registering new partitions in flash memory devices such as NAND. While this function correctly rejects special offset constants like MTDPART_OFS_APPEND and MTDPART_OFS_NXTBLK because they rely on tracking the end of previous partitions, it fails to reject MTDPART_OFS_RETAIN. This oversight stems from a historical inconsistency where static partition table handling was updated to support retention flags without synchronizing the dynamic partition path used by ioctl requests. Consequently, when an attacker or misconfigured user space application passes the value -3 for the offset via the BLKPG ioctl command on NAND devices, the kernel proceeds with invalid arithmetic operations that compromise memory safety and system stability.
The technical root cause lies in how MTDPART_OFS_RETAIN is processed during partition allocation. This special flag expects cur_offset to represent the end of the preceding partition to calculate remaining space correctly. However, in the dynamic path triggered by ioctl calls, cur_offset equals the offset argument itself rather than a cumulative position. When -3 is passed as the offset, the size calculation within allocate_partition undergoes an integer underflow. Specifically, subtracting 0xFFFFFFFFFFFFFFFD from parent_size results in adding three to the parent size instead of calculating remaining space properly. This arithmetic error leads to two distinct failure modes depending on system state and memory layout. In one scenario, if the miscalculated size appears insufficient, the code jumps to a registration label while skipping critical initialization steps, leaving the erasesize field at zero.
This uninitialized or incorrectly initialized state triggers a kernel warning within add_mtd_device because the MTD device structure lacks essential erase capabilities required for proper operation. The presence of this WARN_ON indicates that the driver is attempting to operate on a device with undefined parameters, which can lead to further instability if not caught by higher-level error handling mechanisms. In alternative scenarios where the underflow results in an apparently large enough size, the kernel performs sanity checks that detect the offset as out of reach. Instead of returning a standard error code to indicate invalid input, the system creates a disabled empty partition with zero offset and zero size. While this prevents immediate crash, it represents incorrect state management and leaves residual artifacts in the device tree without providing meaningful feedback about the configuration error.
From a security perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound due to improper handling of signed arithmetic operations that result in unexpected values under specific conditions. Furthermore, because the flaw is exploitable via ioctl interfaces which are accessible by users with appropriate permissions, it relates to CWE-284 Improper Access Control if privilege escalation were possible through subsequent exploitation chains involving the malformed MTD structures. The attack vector corresponds to ATT&CK technique T1059 Command and Scripting Interpreter where local actors can manipulate system configuration parameters via standard API calls. Although currently resulting in warnings or empty partitions, such logic errors often serve as precursors to more severe vulnerabilities like use-after-free or out-of-bounds writes if the zeroed erasesize is later dereferenced without proper validation checks throughout the driver stack.
Mitigation strategies should focus on enforcing strict input validation at the boundary of kernel subsystems handling device configuration. The primary fix involves updating mtd_add_partition to explicitly reject MTDPART_OFS_RETAIN, mirroring the existing rejection logic for other special offset values that depend on partition context rather than absolute positioning. Developers must ensure that all dynamic partition creation paths validate flags and offsets against a comprehensive list of supported constants before proceeding with arithmetic calculations or device registration. Additionally, implementing robust sanity checks in add_mtd_device to verify erasesize integrity prior to any operations can prevent the propagation of malformed states into lower-level driver code. Regular auditing of ioctl handlers for similar inconsistencies between static and dynamic configuration paths is recommended to maintain kernel stability and security posture across Memory Technology Device drivers.