Zephyr Project up to 4.4.1 ext2 ext2_impl.c ext2_init_fs out-of-bounds

Summaryinfo

A vulnerability classified as problematic has been found in Zephyr Project Zephyr up to 4.4.1. Affected by this issue is the function ext2_init_fs of the file subsys/fs/ext2/ext2_impl.c of the component ext2. Performing a manipulation results in out-of-bounds. This vulnerability is identified as CVE-2026-13478. The attack is only possible with local access. There is not any exploit available.

Detailsinfo

A vulnerability, which was classified as problematic, was found in Zephyr Project Zephyr up to 4.4.1. This affects the function ext2_init_fs of the file subsys/fs/ext2/ext2_impl.c of the component ext2. The manipulation with an unknown input leads to a out-of-bounds vulnerability. CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. This is going to have an impact on availability. The summary by CVE is:

The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2_init_fs() (subsys/fs/ext2/ext2_impl.c) by passing fs_blocks = s_blocks_count - s_first_data_block to ext2_bitmap_count_set(). That helper (subsys/fs/ext2/ext2_bitmap.c) treats its argument as a number of bits and reads one bitmap byte per eight bits, but the bitmap buffer (BGROUP_BLOCK_BITMAP) is a single fetched block of only fs->block_size bytes (capacity fs->block_size * 8 bits). s_blocks_count and s_first_data_block are taken verbatim from the superblock and were never bounded against this single-group capacity; ext2_verify_disk_superblock() checks the magic, revision, and block-size shift but not the block count. A crafted ext2 image with an oversized s_blocks_count (up to ~4 billion, against a maximum 4096-byte block / 32768-bit bitmap) makes ext2_bitmap_count_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: ext2_init_fs() is invoked from ext2_mount() (subsys/fs/ext2/ext2_ops.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 fs_blocks exceeds fs->block_size * 8 before the scan.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-13478 since 06/27/2026. The exploitability is told to be easy. An attack has to be approached locally. The exploitation needs additional levels of successful authentication. It demands that the victim is doing some kind of user interaction. Technical details are known, but no exploit is available.

Upgrading to version 4.4.2 eliminates this vulnerability.

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