Cloudanix VulnDB

CVE-2026-93048

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in how the operating system handles certain storage-partition requests on flash memory devices can cause warnings or create invalid partitions, potentially affecting device stability.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

mtd_add_partition() accepts the special offset MTDPART_OFS_RETAIN (-3) via BLKPG ioctl, causing cur_offset to equal the argument, underflow in allocate_partition() size calculation, skipped erasesize initialization, and either a WARN_ON in add_mtd_device() or creation of a disabled empty partition.

Why it matters to the business

Systems using NAND flash with dynamic partition management via ioctl may experience kernel warnings, failed partition operations, or unexpected empty partitions, disrupting storage configuration on embedded and IoT devices.

How an attack unfolds

An attacker with sufficient privileges to issue the BLKPG_ADD_PARTITION ioctl on an MTD NAND device supplies offset=-3; the kernel path through mtd_add_partition() fails to reject the value, allocate_partition() underflows or skips initialization, and add_mtd_device() either emits a warning or registers an invalid partition.

How to fix it

Upgrade the Linux kernel to a version containing the fix that adds MTDPART_OFS_RETAIN to the rejection list inside mtd_add_partition(), matching the existing handling of APPEND and NXTBLK.

How to confirm the fix worked

Confirm the patched kernel rejects MTDPART_OFS_RETAIN with an error rather than proceeding to allocate_partition(); re-test BLKPG_ADD_PARTITION with offset=-3 on NAND devices and verify absence of the erasesize=0 warning path.

Typical attack path

  1. Obtain privileges allowing BLKPG ioctl on target MTD device
  2. Craft partition request with offset set to MTDPART_OFS_RETAIN (-3)
  3. Invoke ioctl to trigger mtd_add_partition()
  4. Observe underflow, skipped erasesize, or resulting WARN_ON / empty partition

How to detect it

Review kernel logs for the specific WARN_ON condition involving erasesize and add_mtd_device triggered during partition ioctls; inspect audit or system-call logs for unusual BLKPG requests containing negative offset values on MTD devices.

What your security team should do

  • Prioritize kernel updates on all systems exposing MTD NAND devices to user-space ioctls
  • Audit custom or third-party code that directly calls mtd_add_partition() or equivalent partition ioctls
  • Monitor for kernel WARN_ON messages referencing erasesize or add_mtd_device during partition operations

The record

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.

Affected packages

Ecosystem Package Introduced Fixed