CVE-2026-93048: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()
In the Linux kernel, the following vulnerability has been resolved:
mtd: part: reject MTDPARTOFSRETAIN in mtdaddpartition()
mtdaddpartition() does not reject the special offset value MTDPARTOFSRETAIN (-3), which leads to a WARNON in addmtddevice() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on curoffset being the end of the previous partition, but in the dynamic partition path curoffset equals the offset argument itself, causing undefined behavior.
Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtdaddpartition() and correctly rejected MTDPARTOFSAPPEND (-1) and MTDPARTOFSNXTBLK (-2), since those special offsets rely on curoffset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPARTOFSRETAIN (-3) for the static partition table path without updating mtdaddpartition() to also reject this value.
With offset=-3 passed via BLKPG, the RETAIN size calculation in allocatepartition() underflows (parentsize - 0xFFFFFFFFFFFFFFFD = parentsize + 3). If the underflow result does not appear to leave enough space, allocatepartition() jumps to outregister via goto, skipping erasesize initialization. This results in erasesize=0, which triggers:
WARNON((!mtd->erasesize || !master->erase) && !(mtd->flags & MTDNOERASE))
in addmtddevice(). 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 MTDPARTOFSRETAIN to the rejection list in mtdaddpartition(), consistent with the existing handling of APPEND and NXTBLK.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected path involves dynamic MTD partition creation through the BLKPG ioctl on NAND devices. Static partition-table handling is described separately and relies on the previous partition offset, unlike the dynamic path.
What does an attacker or triggering process need to do?
It needs to invoke the BLKPG ioctl to add a partition with the special MTDPART_OFS_RETAIN offset value (-3). In this dynamic path, cur_offset is the supplied offset rather than the end of a previous partition, leading to an invalid RETAIN size calculation.
What can be done before the fix is deployed?
Avoid or block dynamic BLKPG partition-add requests that use MTDPART_OFS_RETAIN (-3) against NAND MTD devices. The special RETAIN offset should only be used in the static partition-table context for which it was designed.
How can I determine whether the corrective change is present?
Inspect mtd_add_partition() and verify that it rejects MTDPART_OFS_RETAIN (-3), in addition to MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2). The provided stable-tree references identify backported corrective commits.