CVE-2026-10645: Zephyr ext2 OOB read/DoS

CISO Take

CVE-2026-10645 is a medium-severity vulnerability in the Zephyr RTOS ext2 directory-entry parser where missing validation of the structural relationship between de_rec_len, de_name_len, and block boundaries allows an out-of-bounds read or infinite loop when a crafted ext2 image is mounted. For CISOs managing edge AI infrastructure — Zephyr-based nodes running on-device ML inference with removable storage — the primary risk is denial of service: a malicious SD card swapped during brief physical access can hang or crash the inference service entirely. The physical attack vector (AV:P) keeps this well outside CISA KEV territory and no public exploit exists, making opportunistic exploitation unlikely. Mitigate by patching to the Zephyr release resolving GHSA-hwrh-9h3x-vccm, disabling ext2 support where unused (CONFIG_FILE_SYSTEM_EXT2=n), and enforcing physical access controls and media integrity checks on edge AI nodes.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Low risk for cloud-hosted AI workloads; moderate risk for edge AI and embedded ML inference deployments on Zephyr RTOS that accept removable ext2 media. The physical attack vector strictly eliminates remote exploitation. The OOB read (CWE-125) could expose adjacent directory block buffer memory, but the attacker must have hands-on device access. Blast radius is confined to organizations deploying Zephyr-based edge inference hardware — industrial IoT, predictive maintenance sensors, embedded vision systems — a niche but growing segment of enterprise AI infrastructure.

How does the attack unfold?

Physical Access

Adversary gains brief physical access to a Zephyr-based edge AI inference device equipped with a removable ext2 storage slot (SD card or USB).

AML.T0041

Malicious Media Preparation

Adversary crafts an ext2 image with malformed directory entries near block boundaries — de_rec_len set to zero or de_name_len exceeding the remaining block space — and writes it to removable media.

Filesystem Mount and Traversal

Device mounts the media and the ML inference service triggers directory traversal (pathname lookup, stat, open, readdir) to locate model weights, config files, or sensor input data.

DoS or OOB Read Impact

ext2_fetch_direntry() either enters an infinite loop on de_rec_len==0 — permanently hanging the AI inference service — or performs an oversized memcpy reading out-of-bounds from the directory block buffer, leaking adjacent memory.

AML.T0029

Physical Access

Adversary gains brief physical access to a Zephyr-based edge AI inference device equipped with a removable ext2 storage slot (SD card or USB).

AML.T0041

Malicious Media Preparation

Adversary crafts an ext2 image with malformed directory entries near block boundaries — de_rec_len set to zero or de_name_len exceeding the remaining block space — and writes it to removable media.

Filesystem Mount and Traversal

Device mounts the media and the ML inference service triggers directory traversal (pathname lookup, stat, open, readdir) to locate model weights, config files, or sensor input data.

DoS or OOB Read Impact

ext2_fetch_direntry() either enters an infinite loop on de_rec_len==0 — permanently hanging the AI inference service — or performs an oversized memcpy reading out-of-bounds from the directory block buffer, leaking adjacent memory.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Zephyr	—	—	No patch

Do you use Zephyr? You're affected.

How severe is it?

CVSS 3.1

4.9 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Physical

AC Low

PR None

UI Required

S Unchanged

C Low

I None

A High

What should I do?

1 step

1) Patch: Update Zephyr RTOS to the version resolving GHSA-hwrh-9h3x-vccm; consult the Zephyr security advisory for the exact fixed commit/release tag. 2) Disable: Set CONFIG_FILE_SYSTEM_EXT2=n in Kconfig for any device that does not require ext2 support. 3) Physical controls: Enforce physical access controls, tamper-evident seals, and locked enclosures on edge AI hardware with removable storage slots. 4) Media integrity: Where feasible, cryptographically sign and verify ext2 images before mount; reject unsigned media at the application layer. 5) Detection: Monitor for watchdog resets, abnormal process hangs, or kernel panics on edge inference devices that could indicate triggering of the infinite-loop or OOB path.

How is it classified?

DoS Data Extraction Inference AML.T0029 - Denial of AI Service AML.T0041 - Physical Environment Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.9.3 - AI system operation and monitoring

NIST AI RMF

MANAGE 2.4 - Residual risks are documented and accepted

Frequently Asked Questions

What is CVE-2026-10645?

CVE-2026-10645 is a medium-severity vulnerability in the Zephyr RTOS ext2 directory-entry parser where missing validation of the structural relationship between de_rec_len, de_name_len, and block boundaries allows an out-of-bounds read or infinite loop when a crafted ext2 image is mounted. For CISOs managing edge AI infrastructure — Zephyr-based nodes running on-device ML inference with removable storage — the primary risk is denial of service: a malicious SD card swapped during brief physical access can hang or crash the inference service entirely. The physical attack vector (AV:P) keeps this well outside CISA KEV territory and no public exploit exists, making opportunistic exploitation unlikely. Mitigate by patching to the Zephyr release resolving GHSA-hwrh-9h3x-vccm, disabling ext2 support where unused (CONFIG_FILE_SYSTEM_EXT2=n), and enforcing physical access controls and media integrity checks on edge AI nodes.

Is CVE-2026-10645 actively exploited?

No confirmed active exploitation of CVE-2026-10645 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-10645?

1) Patch: Update Zephyr RTOS to the version resolving GHSA-hwrh-9h3x-vccm; consult the Zephyr security advisory for the exact fixed commit/release tag. 2) Disable: Set CONFIG_FILE_SYSTEM_EXT2=n in Kconfig for any device that does not require ext2 support. 3) Physical controls: Enforce physical access controls, tamper-evident seals, and locked enclosures on edge AI hardware with removable storage slots. 4) Media integrity: Where feasible, cryptographically sign and verify ext2 images before mount; reject unsigned media at the application layer. 5) Detection: Monitor for watchdog resets, abnormal process hangs, or kernel panics on edge inference devices that could indicate triggering of the infinite-loop or OOB path.

What systems are affected by CVE-2026-10645?

This vulnerability affects the following AI/ML architecture patterns: Edge AI inference, Embedded ML ops, IoT ML pipelines.

What is the CVSS score for CVE-2026-10645?

CVE-2026-10645 has a CVSS v3.1 base score of 4.9 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

Edge AI inferenceEmbedded ML opsIoT ML pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0041 Physical Environment Access

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.3

NIST AI RMF: MANAGE 2.4

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An insider threat or attacker with brief unsupervised access to a Zephyr-based industrial edge AI node — for example, a predictive-maintenance sensor running anomaly-detection inference — prepares a malformed ext2 SD card with a directory entry near the end of a block where de_rec_len is set to zero. They swap the legitimate media. On next boot, the ML inference service traverses the filesystem to load model weights or scan input data directories; ext2_fetch_direntry() encounters the malformed entry, fails to advance (de_rec_len==0), and enters an infinite loop — permanently hanging the inference service and triggering a watchdog reset cycle. An alternative payload uses a de_name_len exceeding the block boundary to force memcpy to read past the allocated directory block buffer, potentially leaking adjacent heap or stack contents.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.