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

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

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.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

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). The EPSS exploitation probability is 0.15%.

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

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.

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.