CVE-2026-93048

CVE CVE-2026-93048EUVD EUVD-2026-82158Published 2026-09-17T16:10:39.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 3.2; patch: 0; patch: 7.2.6; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <398aca2f90122d5abbabff1079deaeb885fe9e40; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <b759d5bb6265419344ee9729fd0dc07ad85719d8; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <6aaab2ace3f7b55733d904e5549acf8405f03642; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <701c3ae7273e1adc20db5d97c42e0139b479f16b; patch: 6.18.52; patch: 6.1.188; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <e204e5c49a012f99638633fdbd773e3c86260053; patch: 6.12.110; patch: 5.15.221; patch: 6.6.157; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <a536eb57be58442b19398b2783071007ecfb1735; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <181c1bff940e7d3e34ca485d37e3cdbfe409203c; patch: 7.3-rc1; patch: 5.10.270; 1a31368bf92ef2a7da3ba379672c405bd2751df9 <c645f6dd1af2ecc70fd3578e141f2f71fa9e4eff

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.