Description
The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len > EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.
Published: 2026-06-22
Score: 4.9 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Zephyr ext2 filesystem driver validates the on‑disk directory entry fields de_rec_len and de_name_len incorrectly. The check that de_name_len is greater than EXT2_MAX_FILE_NAME is always false because de_name_len is an 8‑bit value and the maximum file name length is 255, so the driver copy loop can read up to 255 bytes without verifying the actual length. When a directory block is read into a slab buffer exactly the size of the block, a preceding entry with a large rec_len can move the offset close to the block end. The subsequent 8‑byte header read and the name copy then read up to roughly 263 bytes past the buffer, leaking adjacent kernel heap memory through the readdir path. A de_rec_len value of zero also causes a zero‑progress infinite loop, resulting in a denial of service. The unlink path contains an additional out‑of‑bounds read/write source when memmove operates on unvalidated records. These weaknesses together allow an attacker to gain confidential information from the kernel heap and, if the infinite loop is triggered, to crash the system.

Affected Systems

The flaw resides within Zephyr RTOS’s ext2 filesystem driver. Any Zephyr instance that mounts an ext2 volume from media supplied by an attacker is vulnerable. The affected releases span Zephyr ext2 from its introduction in version 3.5.0 through version 4.4.0.

Risk and Exploitability

The CVSS score of 4.9 classifies this issue as moderate severity. The EPSS score of <1% indicates a very low but nonzero chance of exploitation, and the vulnerability is not listed in CISA’s KEV catalog, suggesting it is not actively exploited. Based on the description, it is inferred that an attacker must supply a crafted ext2 image and gain sufficient privilege to mount it on the Zephyr device, typically via physical or network access to the device’s storage media such as an SD card or USB drive. The likely attack vector is therefore local or remote depending on the ability to place the malicious image on a device that will mount it, and the exploitation likelihood remains low without a privileged foothold.

Generated by OpenCVE AI on August 3, 2026 at 07:17 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Zephyr release that incorporates the ext2 parsing validation fix
  • Block or disable mounting of untrusted ext2 filesystems, or enforce integrity checks on ext2 images before mounting
  • If upgrading is not immediately possible, restrict physical and logical access to the device’s storage media and limit privileged users from performing mount operations

Generated by OpenCVE AI on August 3, 2026 at 07:17 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 14 Jul 2026 19:00:00 +0000

Type Values Removed Values Added
Description Zephyr's ext2 directory-entry parser does not fully validate on-disk directory entry structure before copying the entry name and advancing traversal state. In ext2_fetch_direntry() (subsys/fs/ext2/ext2_diskops.c), the code only checks de_name_len <= EXT2_MAX_FILE_NAME and then copies the name with memcpy without validating the structural relationship between de_rec_len, de_name_len, and the directory block boundary (for example that de_rec_len is non-zero, at least the size of the entry header, and that the record fits within the block). Callers such as find_dir_entry() and ext2_get_direntry() (subsys/fs/ext2/ext2_impl.c) then advance traversal using the unvalidated de_rec_len. A crafted ext2 image can therefore cause an out-of-bounds read from the directory block buffer when a malformed entry near the end of a block triggers an oversized name copy, or a zero-progress infinite loop when de_rec_len == 0. The issue is not reached at mount time but later through directory traversal paths such as pathname lookup, stat/open/unlink/rename, and readdir. The primary impact is denial of service and out-of-bounds reads under attacker-controlled ext2 images mounted from untrusted media. The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len > EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.
Title fs: ext2: Missing structural validation of directory entries can cause out-of-bounds read and zero-progress directory traversal Out-of-bounds read in Zephyr ext2 directory entry traversal from a crafted filesystem image
References

Tue, 23 Jun 2026 13:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

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


Tue, 23 Jun 2026 02:45:00 +0000

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

Tue, 23 Jun 2026 00:30:00 +0000

Type Values Removed Values Added
Description Zephyr's ext2 directory-entry parser does not fully validate on-disk directory entry structure before copying the entry name and advancing traversal state. In ext2_fetch_direntry() (subsys/fs/ext2/ext2_diskops.c), the code only checks de_name_len <= EXT2_MAX_FILE_NAME and then copies the name with memcpy without validating the structural relationship between de_rec_len, de_name_len, and the directory block boundary (for example that de_rec_len is non-zero, at least the size of the entry header, and that the record fits within the block). Callers such as find_dir_entry() and ext2_get_direntry() (subsys/fs/ext2/ext2_impl.c) then advance traversal using the unvalidated de_rec_len. A crafted ext2 image can therefore cause an out-of-bounds read from the directory block buffer when a malformed entry near the end of a block triggers an oversized name copy, or a zero-progress infinite loop when de_rec_len == 0. The issue is not reached at mount time but later through directory traversal paths such as pathname lookup, stat/open/unlink/rename, and readdir. The primary impact is denial of service and out-of-bounds reads under attacker-controlled ext2 images mounted from untrusted media.
Title fs: ext2: Missing structural validation of directory entries can cause out-of-bounds read and zero-progress directory traversal
Weaknesses CWE-125
References
Metrics cvssV3_1

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


Subscriptions

Zephyrproject-rtos Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-07-14T18:38:33.907Z

Reserved: 2026-06-02T15:11:47.668Z

Link: CVE-2026-10645

cve-icon Vulnrichment

Updated: 2026-06-23T12:22:00.484Z

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-03T07:30:04Z

Weaknesses