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.