CVE-2026-13478: Out-of-bounds read in Zephyr ext2 block-bitmap validation from a crafted s_blocks_count
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; ext2verifydisksuperblock() 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 ext2bitmapcountset() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In ext2_bitmap_count_set() (subsys/fs/ext2/ext2_bitmap.c) path used by ext2_init_fs() (subsys/fs/ext2/ext2_impl.c), add a validation in ext2_init_fs(): compute fs_blocks = s_blocks_count - s_first_data_block and reject the mount/image if fs_blocks exceeds fs->block_size * 8 (the single block bitmap capacity).
Zephyr ext2 filesystem driver reject images when fs_blocks > fs->block_size * 8 before ext2_bitmap_count_set() scan = enforced
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Zephyr ext2 filesystem driver are exposed when they mount an attacker-supplied ext2 image. Relevant ingestion paths include removable media and any other mechanism that permits an untrusted image to be mounted.
What does an attacker need to trigger the problem?
An attacker needs the ability to provide an ext2 image that the target mounts. The image must contain a superblock with an oversized s_blocks_count relative to s_first_data_block; no user interaction is required once the mount occurs.
What is the likely impact during exploitation?
The malformed block count causes validation to read beyond the single fetched bitmap block, potentially scanning roughly 512 MB of adjacent memory. The provided vector indicates local access, low attack complexity, low privileges, and an availability impact, with no stated confidentiality or integrity impact.