CVE-2026-13478

The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2initfs() (subsys/fs/ext2/ext2impl.c) by passing fsblocks = sblockscount - sfirstdatablock to ext2bitmapcountset(). That helper (subsys/fs/ext2/ext2bitmap.c) treats its argument as a number of bits and reads one bitmap byte per eight bits, but the bitmap buffer (BGROUPBLOCKBITMAP) is a single fetched block of only fs->blocksize bytes (capacity fs->blocksize * 8 bits). sblockscount and sfirstdatablock are taken verbatim from the superblock and were never bounded against this single-group capacity; ext2verifydisk_superblock() checks the magic, revision, and block-size shift but not the block count.

A crafted ext2 image with an oversized sblockscount (up to ~4 billion, against a maximum 4096-byte block / 32768-bit bitmap) makes ext2bitmapcount_set() scan roughly 512 MB of memory past the bitmap block — a large out-of-bounds read of the static block slab and adjacent memory.

The defect is reached during mount: ext2initfs() is invoked from ext2mount() (subsys/fs/ext2/ext2ops.c), the registered .mount operation. Any path that mounts an attacker-supplied ext2 image (removable media, a disk/flash partition, or a downloaded image) triggers it. The kernel-privileged parser operates on attacker-controlled data, so the bug is exploitable wherever untrusted ext2 media can be mounted.

Impact is an out-of-bounds read only: the resulting bit count is compared internally and the mount is rejected, so no attacker-controlled bytes are returned (not a useful information leak). The ~512 MB over-read will almost certainly cross an unmapped or MPU-protected boundary and fault, crashing the system — a denial of service triggered by mounting a single malformed image. The fix rejects any image whose fsblocks exceeds fs->blocksize * 8 before the scan.