CVE-2026-13215 in Zephyr
Summary
by MITRE • 08/25/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The Zephyr ext2 filesystem driver contains a critical input validation flaw within the superblock verification logic, specifically regarding the s_log_block_size field found in the on-disk metadata structure. When mounting an ext2 filesystem, the function ext2_verify_disk_superblock located in subsys/fs/ext2/ext2_impl.c performs several integrity checks including validating the magic number, revision level, inode size, and group counts. However, it fails to enforce bounds checking on the s_log_block_size field, which is a uint32_t value that dictates the logical block size of the filesystem. This oversight allows an attacker who can supply a crafted ext2 image through removable media such as SD cards or other storage devices to inject arbitrary values into this field without triggering any validation errors during the initial mount phase.
The operational impact stems from how the driver utilizes this unchecked value in subsys/fs/ext2/ext2_ops.c. Upon successful verification, the code computes the actual block size by performing a bitwise left shift operation: fs->block_size = 1024 << superblock.s_log_block_size. If an attacker provides a s_log_block_size value greater than eleven, this calculation results in undefined behavior due to integer overflow or produces a block size that vastly exceeds the configured maximum limit defined by CONFIG_EXT2_MAX_BLOCK_SIZE. This miscalculated block size is subsequently passed to k_mem_slab_init() via ext2_init_blocks_slab(), which attempts to initialize a memory slab for managing filesystem blocks using a fixed static buffer named __ext2_block_memory_buffer. The size of this backing buffer is strictly defined as CONFIG_EXT2_MAX_BLOCK_COUNT multiplied by CONFIG_EXT2_MAX_BLOCK_SIZE, representing the maximum safe capacity for block storage within the kernel's static memory allocation.
The vulnerability escalates because k_mem_slab_init() does not verify whether the requested number and size of blocks fit within the provided buffer boundaries. Furthermore, the ext2 driver wrapper code discards the return value from this initialization function, meaning any errors or failures in slab creation are silently ignored. Consequently, when a crafted image with an oversized block size is mounted, the memory slab is laid out past the end of the static __ext2_block_memory_buffer. As soon as the filesystem mount process proceeds to read essential metadata such as block-group descriptors, bitmap blocks, and inode tables, it performs writes into these improperly allocated slab blocks. This results in immediate out-of-bounds writes into adjacent static memory regions within the kernel space.
This vulnerability represents a severe security risk classified under CWE-120 Buffer Copy without Checking Size of Input Classic Buffer Overflow and CWE-787 Out-of-bounds Write. From an offensive perspective, it aligns with ATT&CK techniques involving exploitation for privilege escalation or denial of service through memory corruption. Because the ext2 driver operates in supervisor mode within the Zephyr RTOS kernel environment, exploiting this flaw allows any attacker with physical access to present a malicious storage medium to achieve arbitrary code execution or cause a system crash. The lack of input validation on critical filesystem parameters effectively turns standard mount operations into a remote code execution primitive when combined with removable media vectors.
The remediation for this issue involves implementing strict bounds checking within the superblock verification process. Specifically, the ext2_verify_disk_superblock function must reject any s_log_block_size values that would cause an overflow during the shift operation or result in a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE. By ensuring that the calculated block size remains within predefined limits before proceeding to memory slab initialization, the driver prevents the allocation of oversized slabs and eliminates the possibility of out-of-bounds writes into adjacent static memory structures. This fix ensures that only valid filesystem images with compliant block sizes are mounted, thereby preserving the integrity of kernel memory allocations during storage operations.