Description
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.
Published: 2026-08-25
Score: 6.8 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory corruption that can lead to denial of service or potential execution of arbitrary code
Action: Immediate Patch
AI Analysis

Impact

The Zephyr RTOS ext2 filesystem driver does not validate the superblock field that determines block size. When mounting a filesystem, a crafted value can cause the driver to compute an excessively large block size, leading to a memory slab allocation that overruns its backing buffer. The resulting out‑of‑bounds write corrupts adjacent static memory while the driver reads initial filesystem blocks, giving an attacker a kernel‑level memory‑corruption primitive that can be leveraged for denial of service or code execution.

Affected Systems

This issue affects the Zephyr RTOS ext2 filesystem driver in the Zephyr project. No specific version information is provided, so any Zephyr build that includes the unpatched ext2 implementation may be vulnerable.

Risk and Exploitability

The CVSS score of 6.8 indicates high severity. The analysis does not include an EPSS score, but the vulnerability is not listed in CISA KEV. Because the flaw is triggered by a crafted ext2 image presented to a device that mounts it (e.g., a removable SD card or other storage medium), the attack requires local access to supply the image. The exploit path is straightforward: supply the malicious filesystem, trigger mount, and obtain kernel‑mode memory corruption. The impact ranges from denial of service to privilege escalation depending on how the memory corruption is leveraged.

Generated by OpenCVE AI on August 25, 2026 at 05:20 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Zephyr release that includes the patch from commit f270f4bd0e59585da31e1fbaa79c5abf73f1364b or the advisory GHSA‑j52j‑gfj9‑rwjm
  • Verify that the ext2 driver configuration limits block sizes to CONFIG_EXT2_MAX_BLOCK_SIZE and rejects values greater than 11 for s_log_block_size
  • Restrict or disable mounting of ext2 filesystems from untrusted external media, or otherwise ensure that only trusted users can mount such filesystems

Generated by OpenCVE AI on August 25, 2026 at 05:20 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 27 Aug 2026 06:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Tue, 25 Aug 2026 05:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Tue, 25 Aug 2026 04:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Zephyr ext2 mount: unvalidated superblock block size causes out-of-bounds write from a crafted filesystem image
Weaknesses CWE-787
References
Metrics cvssV3_1

{'score': 6.8, 'vector': 'CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-08-25T15:15:11.838Z

Reserved: 2026-06-24T15:29:24.406Z

Link: CVE-2026-13215

cve-icon Vulnrichment

Updated: 2026-08-25T15:15:07.615Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-08-25T05:17:20.187

Modified: 2026-08-26T16:59:23.267

Link: CVE-2026-13215

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-25T05:30:16Z

Weaknesses