CVE-2026-13215: Zephyr ext2 Filesystem Driver RCE Vulnerability

CVE-2026-13215 Overview

CVE-2026-13215 is an out-of-bounds write vulnerability [CWE-787] in the Zephyr real-time operating system (RTOS) ext2 filesystem driver. The driver fails to validate the s_log_block_size field of the on-disk ext2 superblock during mount. An attacker who can present a crafted ext2 image, such as via a removable SD card, can trigger memory corruption in kernel mode. The flaw enables writes past the end of the static block buffer used by the ext2 slab allocator.

Critical Impact
Physical presentation of a malicious ext2 image yields a supervisor-mode memory-corruption primitive, ranging from denial of service to potential code execution on Zephyr devices.

Affected Products

Zephyr Project RTOS (ext2 filesystem driver in subsys/fs/ext2/)
Devices mounting untrusted ext2-formatted removable storage
Builds using CONFIG_EXT2_MAX_BLOCK_SIZE and CONFIG_EXT2_MAX_BLOCK_COUNT

Discovery Timeline

2026-08-25 - CVE-2026-13215 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-13215

Vulnerability Analysis

The vulnerability resides in ext2_verify_disk_superblock() in subsys/fs/ext2/ext2_impl.c. The function validates the magic number, revision, inode size, and group counts. It never bounds the attacker-controlled s_log_block_size field. Upon successful verification, subsys/fs/ext2/ext2_ops.c computes fs->block_size = 1024 << superblock.s_log_block_size from that untrusted uint32_t value.

A crafted value either overflows the shift, producing undefined behavior, or yields a block size larger than CONFIG_EXT2_MAX_BLOCK_SIZE. The oversized block size then flows into ext2_init_blocks_slab(), which calls k_mem_slab_init() to carve CONFIG_EXT2_MAX_BLOCK_COUNT blocks from the static buffer __ext2_block_memory_buffer.

Root Cause

Two defects compound the issue. k_mem_slab_init() does not verify that the requested slab fits its backing buffer. The ext2 wrapper discards the return value, so the slab is laid out past the end of the static allocation. Subsequent reads of block-group, bitmap, and inode blocks write attacker-controlled bytes into adjacent static kernel memory on the first block read.

Attack Vector

The entire mount path is gated only by data read from the mounted image. Any attacker who can present a crafted ext2 image, such as through an SD card or USB storage medium, can reach the vulnerable code. Because the ext2 driver executes in kernel mode, the attacker obtains a supervisor-mode write primitive without authentication or user interaction beyond mounting.

		return -EINVAL;
	}

+	/* Block size is computed as 1024 << s_log_block_size and is used to size
+	 * the static block slab. A crafted value would overflow the shift and/or
+	 * exceed the statically configured maximum block size, corrupting the
+	 * allocator. The first term guards the shift against undefined behaviour.
+	 */
+	if (sys_le32_to_cpu(sb->s_log_block_size) > 11U ||
+	    (1024U << sys_le32_to_cpu(sb->s_log_block_size)) > CONFIG_EXT2_MAX_BLOCK_SIZE) {
+		LOG_ERR("Filesystem block size is too large");
+		return -ENOTSUP;
+	}
+
	/* Check if file system may contain errors. */
	if (sys_le16_to_cpu(sb->s_state) == EXT2_ERROR_FS) {
		LOG_WRN("File system may contain errors.");

Source: Zephyr commit f270f4bd0e59585da31e1fbaa79c5abf73f1364b

Detection Methods for CVE-2026-13215

Indicators of Compromise

Zephyr log entries containing LOG_ERR("Filesystem block size is too large") on patched builds, indicating a rejected malicious image.
Unexpected device resets, kernel faults, or watchdog reboots immediately following an ext2 mount operation.
Presence of ext2 images with s_log_block_size values greater than 11 in removable media inserted into deployed devices.

Detection Strategies

Statically inspect ext2 images offered to Zephyr devices and verify the superblock s_log_block_size field falls within a supported range.
Instrument test builds to log the computed fs->block_size value on mount and alert when it exceeds CONFIG_EXT2_MAX_BLOCK_SIZE.
Fuzz the ext2 mount path with malformed superblocks in pre-deployment validation to reproduce the memory corruption.

Monitoring Recommendations

Audit firmware logs from fielded devices for repeated mount failures or crashes correlated with removable media insertion.
Track deployment of Zephyr firmware versions across fleets and flag builds predating commit f270f4b.
Monitor supply-chain sources for pre-formatted storage media presented to embedded systems in sensitive environments.

How to Mitigate CVE-2026-13215

Immediate Actions Required

Rebuild affected Zephyr firmware with the upstream fix from commit f270f4bd0e59585da31e1fbaa79c5abf73f1364b applied to subsys/fs/ext2/ext2_impl.c.
Restrict physical access to devices that mount ext2-formatted removable storage in production environments.
Disable automatic mounting of untrusted removable media where the ext2 driver is enabled.

Patch Information

The Zephyr Project resolved the issue by bounding s_log_block_size during superblock verification. The patch rejects values greater than 11 or values that produce a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE, returning -ENOTSUP before the block slab is initialized. Full technical details are available in the GitHub Security Advisory GHSA-j52j-gfj9-rwjm and the upstream commit.

Workarounds

Disable CONFIG_FILE_SYSTEM_EXT2 in Kconfig for builds that do not require ext2 support.
Require signed or attested storage media and reject filesystem images that fail integrity checks before invoking fs_mount().
Lower CONFIG_EXT2_MAX_BLOCK_SIZE to the minimum required by the application to shrink the exploitable slab window while awaiting the patched build.

bash

# Configuration example: disable ext2 support in prj.conf
CONFIG_FILE_SYSTEM_EXT2=n

# Or bound the maximum block size for builds that must retain ext2
CONFIG_EXT2_MAX_BLOCK_SIZE=1024