CVE-2026-10645: Zephyr ext2 Directory Entry Out-of-Bounds Memory Read & Denial of Service

Technical summary

The ext2_fetch_direntry() function in Zephyr's ext2 driver (subsys/fs/ext2) fails to properly validate two critical fields in directory entry headers: de_rec_len (record length) and de_name_len (name length). The name_len field is a uint8_t with a maximum value of 255, and the driver only checks if de_name_len exceeds EXT2_MAX_FILE_NAME (also 255), making the guard condition permanently false. This allows the driver to memcpy up to 255 bytes into a fixed buffer regardless of actual data present. More critically, de_rec_len is never validated before use; it controls how many bytes the parser advances within a block. Since directory blocks are stored in fixed-size slab buffers, a malicious de_rec_len can position the next entry read near or past the block boundary, enabling reads of 8-byte headers and subsequent name data (up to ~263 bytes total) into adjacent heap memory. The unlink code path compounds the risk by performing memmove() operations on unvalidated record lengths, creating out-of-bounds write exposure. A de_rec_len of zero causes infinite loop, triggering denial of service. Heap memory contents are leaked via the readdir() path, which returns directory entry names to userspace. The defect is reachable through any VFS operation (open, stat, unlink, rename, mkdir) or directory enumeration on a mounted ext2 volume.

Business impact

This vulnerability poses a layered risk depending on deployment context. In IoT and embedded systems where Zephyr is common, an attacker with ability to supply removable storage can leak sensitive kernel memory (potentially revealing cryptographic keys, memory addresses for ASLR bypass, or authentication tokens), trigger denial of service (causing device hang or reboot loops), or corrupt heap state leading to further exploitation. For devices that accept untrusted images (smart home hubs, industrial controllers with USB ports, development boards in lab environments), the barrier to exploitation is low: the attacker simply provides a malicious USB drive or SD card. Even in sandboxed or isolated systems, heap leaks can undermine isolation boundaries. Organizations deploying Zephyr-based products should assess whether end-users or field technicians have access to mount untrusted ext2 filesystems, and whether kernel memory in use might contain secrets.

Affected systems

Zephyr Project versions 3.5.0 through 4.4.0 are affected. The vulnerability resides in the ext2 filesystem driver and is triggered only when an ext2 volume is mounted and accessed. Systems using other filesystems (FAT, LITTLEFS, etc.) are not affected. Risk is highest for deployments that mount user-supplied or externally-sourced ext2 storage, or that accept ext2 disk images from untrusted sources. Zephyr 4.5.0 and later contain mitigations; users of versions 3.5.0–4.4.0 remain exposed.

Exploitability

Exploitability is straightforward for attackers with ability to supply storage. No authentication or elevated privileges are required—a crafted ext2 filesystem on a USB drive or SD card triggers the flaw upon mount and basic directory operations. The attack surface is wide: open, stat, unlink, rename, mkdir, and readdir all exercise the vulnerable code paths. The barrier to practical exploitation is manufacturing a malicious ext2 image, which is well within reach of any threat actor with basic filesystem knowledge. However, reliable exploitation for code execution requires additional heap grooming or spray techniques; the primary exploitable outcomes are denial of service (infinite loop via de_rec_len = 0) and information disclosure (heap memory leak via readdir). CVSS vector AV:P (physical or local) reflects that an attacker must mount storage locally; AC:L indicates no special conditions are required once an ext2 image is supplied; UI:R acknowledges user interaction (mounting the filesystem) but is a minor hurdle in unattended or automated scenarios.

Remediation

Apply patches from Zephyr 4.5.0 or later, which validate de_rec_len and de_name_len on every directory entry traversal. Verification steps: confirm that the ext2 parser rejects entries whose record length would overrun the block boundary, and that name lengths are bounded to the remaining space after the entry header. For versions 3.5.0–4.4.0, backport patches if available from the Zephyr security advisory or apply a kernel isolation strategy (e.g., mount ext2 volumes in a restricted namespace or disable ext2 support entirely if not in use). Mitigations: disable ext2 driver compilation if ext2 support is unnecessary for your product; restrict mount permissions to authenticated administrators; scan or validate ext2 images before mounting from external sources.

Patch guidance

Upgrade to Zephyr 4.5.0 or a later stable release. Before upgrading, verify your current version (zephyr --version or check VERSION file) and confirm that ext2 support is active in your build configuration (CONFIG_FILE_SYSTEM_EXT2 or similar). If upgrading is not immediately feasible, consult the official Zephyr security advisories for backported patches applicable to your version. Test upgrades in a controlled environment to ensure compatibility with your application and dependent modules, particularly those relying on ext2 for logging or data persistence.

Detection guidance

On systems running Zephyr versions 3.5.0–4.4.0 with ext2 enabled, monitor for abnormal behavior associated with directory operations: kernel panics or hangs after mounting ext2 volumes, repeated system crashes or resets, or unexpected memory corruption patterns. If heap memory leaks are suspected, enable kernel memory sanitizers (if available) or heap debugging tools during development. Review filesystem mounting logs and block device attachment events to identify when untrusted ext2 images are mounted. Use static analysis tools on Zephyr builds to check for CONFIG_FILE_SYSTEM_EXT2 status; disable it if not required. For forensics, examine crafted ext2 images for malformed directory entries with suspicious de_rec_len or de_name_len values (e.g., de_name_len = 0xFF, de_rec_len = 0 or very large values).

Why prioritize this

Despite a CVSS score of 4.9 (MEDIUM), this vulnerability merits higher-than-baseline attention in embedded and IoT contexts. The combination of straightforward exploitability (supply a malicious USB drive), multiple impact vectors (denial of service, information disclosure), and broad reachability (any filesystem operation) creates practical risk. The primary concern is information disclosure: heap memory leaks can expose cryptographic keys or pointers useful for further attacks. Secondary concern is denial of service in mission-critical IoT systems. Organizations should prioritize patching systems that accept removable or external storage, or that process ext2 filesystems from untrusted sources. Systems without ext2 support or that operate in fully controlled environments can deprioritize.

Risk score, explained

The CVSS 3.1 score of 4.9 reflects a physical attack vector (AV:P), low complexity (AC:L), no privilege requirement (PR:N), and limited scope (S:U). The impact is low confidentiality (C:L) from heap leaks and high availability (A:H) from denial-of-service loops. However, CVSS underweights the practical risk in embedded deployments where removable storage is common and heap leaks are particularly damaging. Organizations should consider context: a consumer IoT device with USB support poses higher actual risk than the CVSS score suggests, while a sealed industrial controller with no external ports poses lower risk.

Frequently asked questions