CVE-2026-13215: Zephyr ext2 mount: unvalidated superblock block size causes out-of-bounds write from a crafted filesystem image
The Zephyr ext2 filesystem driver fails to validate the slogblocksize field of the on-disk superblock when mounting a filesystem. ext2verifydisksuperblock() in subsys/fs/ext2/ext2impl.c checks the magic number, revision, inode size and group counts, but never bounds slogblocksize. On a successful verify, subsys/fs/ext2/ext2ops.c computes fs->blocksize = 1024 << superblock.slogblocksize from this attacker-controlled uint32t, so a crafted value either overflows the shift (undefined behaviour) or yields a block size far larger than CONFIGEXT2MAXBLOCKSIZE.
That block size is then passed to kmemslabinit() by ext2initblocksslab() to carve CONFIGEXT2MAXBLOCKCOUNT blocks out of the fixed static buffer ext2blockmemorybuffer, whose size is CONFIGEXT2MAXBLOCKCOUNT CONFIGEXT2MAXBLOCKSIZE. kmemslabinit() 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->blocksize 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 slogblocksize values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIGEXT2MAXBLOCKSIZE, so the block slab can no longer be initialized larger than its backing buffer.
Affected Software
Event History
Frequently Asked Questions
What must an attacker be able to do to exploit this issue?
An attacker needs to provide a crafted ext2 filesystem image that the target mounts. The malicious image sets the on-disk s_log_block_size field to a value that produces an invalid or oversized filesystem block size.
Which systems are exposed?
Systems using the Zephyr ext2 filesystem driver are exposed when they mount attacker-controlled ext2 images. The vulnerable path uses a fixed static ext2 block-memory buffer sized by CONFIG_EXT2_MAX_BLOCK_COUNT and CONFIG_EXT2_MAX_BLOCK_SIZE.
What happens during a malicious mount?
After accepting the malformed superblock, the driver initializes its memory slab using the attacker-derived block size without ensuring the blocks fit the static buffer. The mount then reads filesystem metadata blocks using that size, causing out-of-bounds writes into adjacent static memory.