Zephyr Project up to 4.4.1 ext2 filesystem driver ext2_impl.c ext2_verify_disk_superblock s_log_block_size out-of-bounds write

Summaryinfo

A vulnerability has been found in Zephyr Project Zephyr up to 4.4.1 and classified as very critical. The impacted element is the function ext2_verify_disk_superblock of the file subsys/fs/ext2/ext2_impl.c of the component ext2 filesystem driver. Performing a manipulation of the argument s_log_block_size results in out-of-bounds write. This vulnerability is cataloged as CVE-2026-13215. The attack must be initiated from a local position. There is no exploit available.

Detailsinfo

A vulnerability classified as very critical has been found in Zephyr Project Zephyr up to 4.4.1. This affects the function ext2_verify_disk_superblock of the file subsys/fs/ext2/ext2_impl.c of the component ext2 filesystem driver. The manipulation of the argument s_log_block_size with an unknown input leads to a out-of-bounds write vulnerability. CWE is classifying the issue as CWE-787. The product writes data past the end, or before the beginning, of the intended buffer. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

The Zephyr ext2 filesystem driver fails to validate the s_log_block_size field of the on-disk superblock when mounting a filesystem. ext2_verify_disk_superblock() in subsys/fs/ext2/ext2_impl.c checks the magic number, revision, inode size and group counts, but never bounds s_log_block_size. On a successful verify, subsys/fs/ext2/ext2_ops.c computes fs->block_size = 1024 << superblock.s_log_block_size from this attacker-controlled uint32_t, so a crafted value either overflows the shift (undefined behaviour) or yields a block size far larger than CONFIG_EXT2_MAX_BLOCK_SIZE. That block size is then passed to k_mem_slab_init() by ext2_init_blocks_slab() to carve CONFIG_EXT2_MAX_BLOCK_COUNT blocks out of the fixed static buffer __ext2_block_memory_buffer, whose size is CONFIG_EXT2_MAX_BLOCK_COUNT * CONFIG_EXT2_MAX_BLOCK_SIZE. k_mem_slab_init() does not verify that the requested blocks fit the buffer, and the ext2 wrapper discards its return value, so the slab is laid out past the end of the static buffer. The mount immediately reads block-group, bitmap and inode blocks of fs->block_size bytes each into these slab blocks, producing an out-of-bounds write into adjacent static memory on the first block read. The entire path is gated only by data read from the mounted image, making this reachable by any attacker who can present a crafted ext2 image to a device that mounts it (for example a removable SD card or storage medium). Because the ext2 driver runs in kernel mode, supplying image bytes yields a supervisor-mode memory-corruption primitive, with impact ranging from denial of service to potential code execution. The fix rejects s_log_block_size values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE, so the block slab can no longer be initialized larger than its backing buffer.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-13215 since 06/24/2026. The exploitability is told to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 08/25/2026).

Upgrading to version 4.4.2 eliminates this vulnerability. Applying the patch f270f4bd0e59585da31e1fbaa79c5abf73f1364b is able to eliminate this problem.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-65292). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• Zephyr Project

Name

• Zephyr

Version

• 4.4.0
• 4.4.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion