CVE-2026-7007: zephyr ext2 mount DoS

CISO Take

Zephyr RTOS's ext2 filesystem driver fails to check that two on-disk superblock fields, s_blocks_per_group and s_inodes_per_group, are non-zero before using them as divisors during mount, so a crafted ext2 image with either field zeroed triggers an integer division by zero. On ARMv7-M/ARMv8-M Cortex-M targets with divide-by-zero trapping enabled, this becomes a fatal UsageFault that halts the device — relevant to CISOs running edge-AI or embedded inference deployments on Zephyr-based hardware that accept removable SD cards or USB drives for data collection or model/firmware updates, since a single hostile card causes denial of service with no credentials or network access needed (AV:P, PR:N, UI:N). There is no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a low-likelihood, physical-access-only bug rather than something being actively weaponized. The fix is already merged upstream (commit babc0900); confirm your Zephyr build includes the ext2_verify_disk_superblock() validation, and until then treat removable media on production edge devices as untrusted input requiring inspection or restriction.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium severity (CVSS 4.6) with impact limited purely to availability (C:N/I:N/A:H) — no confidentiality or integrity loss is possible since the flaw is a divisor consumed only for arithmetic, not a memory-corruption primitive. Exploitability is low-complexity (AC:L) but gated by physical/local access (AV:P) — an attacker must be able to physically present a crafted ext2-formatted device to the target, ruling out remote, network, or web-based exploitation. No EPSS score, no CISA KEV listing, and no known public exploit or scanner template exist, indicating no evidence of active or opportunistic exploitation. Real-world risk is concentrated in scenarios with weak physical security around device I/O ports (kiosks, field-deployed sensors, unattended embedded hardware) rather than cloud or datacenter AI infrastructure.

How does the attack unfold?

Initial Access

Attacker gains physical access to a Zephyr-based edge device and prepares a crafted ext2 image with s_blocks_per_group or s_inodes_per_group set to zero on removable media.

AML.T0041

Trigger

The crafted SD card or USB drive is inserted and auto-mounted, invoking ext2_init_fs() and the unvalidated superblock fields.

Exploitation

get_ngroups() or get_itable_entry() divides by the zeroed field, causing an integer division by zero during mount-time initialization.

Impact

On Cortex-M targets with divide-by-zero trapping enabled, the resulting UsageFault is treated as fatal, crashing/rebooting the device and denying availability.

AML.T0029

Initial Access

Attacker gains physical access to a Zephyr-based edge device and prepares a crafted ext2 image with s_blocks_per_group or s_inodes_per_group set to zero on removable media.

AML.T0041

Trigger

The crafted SD card or USB drive is inserted and auto-mounted, invoking ext2_init_fs() and the unvalidated superblock fields.

Exploitation

get_ngroups() or get_itable_entry() divides by the zeroed field, causing an integer division by zero during mount-time initialization.

Impact

On Cortex-M targets with divide-by-zero trapping enabled, the resulting UsageFault is treated as fatal, crashing/rebooting the device and denying availability.

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.6 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Physical

AC Low

PR None

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

Update Zephyr to a version incorporating commit babc0900 (ext2_verify_disk_superblock() now rejects zero s_blocks_per_group/s_inodes_per_group before mount). Where an immediate update isn't possible, restrict physical access to USB/SD interfaces on deployed devices (disable auto-mount, lock or tamper-evident-seal ports) and only allow trusted, pre-vetted, ideally signed removable media to be mounted. For detection, monitor device fleet telemetry for unexpected reboots or fatal-fault resets correlated with media insertion events, and validate ext2 images offline before provisioning them to field devices.

How is it classified?

DoS Inference AML.T0041 - Physical Environment Access

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - AI system operation and monitoring

NIST AI RMF

MEASURE 2.7 - AI system resilience to unauthorized changes or physical tampering

Frequently Asked Questions

What is CVE-2026-7007?

Zephyr RTOS's ext2 filesystem driver fails to check that two on-disk superblock fields, s_blocks_per_group and s_inodes_per_group, are non-zero before using them as divisors during mount, so a crafted ext2 image with either field zeroed triggers an integer division by zero. On ARMv7-M/ARMv8-M Cortex-M targets with divide-by-zero trapping enabled, this becomes a fatal UsageFault that halts the device — relevant to CISOs running edge-AI or embedded inference deployments on Zephyr-based hardware that accept removable SD cards or USB drives for data collection or model/firmware updates, since a single hostile card causes denial of service with no credentials or network access needed (AV:P, PR:N, UI:N). There is no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a low-likelihood, physical-access-only bug rather than something being actively weaponized. The fix is already merged upstream (commit babc0900); confirm your Zephyr build includes the ext2_verify_disk_superblock() validation, and until then treat removable media on production edge devices as untrusted input requiring inspection or restriction.

Is CVE-2026-7007 actively exploited?

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

How to fix CVE-2026-7007?

Update Zephyr to a version incorporating commit babc0900 (ext2_verify_disk_superblock() now rejects zero s_blocks_per_group/s_inodes_per_group before mount). Where an immediate update isn't possible, restrict physical access to USB/SD interfaces on deployed devices (disable auto-mount, lock or tamper-evident-seal ports) and only allow trusted, pre-vetted, ideally signed removable media to be mounted. For detection, monitor device fleet telemetry for unexpected reboots or fatal-fault resets correlated with media insertion events, and validate ext2 images offline before provisioning them to field devices.

What systems are affected by CVE-2026-7007?

This vulnerability affects the following AI/ML architecture patterns: edge/embedded inference, on-device AI deployments, IoT sensor gateways.

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

CVE-2026-7007 has a CVSS v3.1 base score of 4.6 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

edge/embedded inferenceon-device AI deploymentsIoT sensor gateways

MITRE ATLAS Techniques

AML.T0041 Physical Environment Access

Compliance Controls Affected

ISO 42001: A.6.2.2

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

The Zephyr ext2 file system validates the on-disk superblock in ext2_verify_disk_superblock() (subsys/fs/ext2/ext2_impl.c) before completing a mount. The validator checked the magic number, block size, revision and feature flags, but did not verify that the on-disk fields s_blocks_per_group and s_inodes_per_group are non-zero. Both fields are read directly from the image and are later used as divisors during mount-time initialization. During mount, get_ngroups() divides and modulos s_blocks_count by s_blocks_per_group (reached via ext2_fetch_block_group() from ext2_init_fs()), and get_itable_entry() divides (ino - 1) by s_inodes_per_group when fetching the root inode (both in subsys/fs/ext2/ext2_diskops.c). A superblock with either field set to zero therefore causes an integer division by zero during the mount sequence. An attacker who can present a crafted ext2 image to a device that mounts ext2 — removable media such as an SD card or a USB mass-storage device — can trigger this. On ARMv7-M / ARMv8-M-mainline Cortex-M targets, divide-by-zero trapping is enabled (SCB_CCR_DIV_0_TRP), so the division raises a UsageFault that Zephyr treats as a fatal error, producing a denial of service. The impact is limited to availability; the malformed value is consumed only as a divisor. The fix rejects a zero s_blocks_per_group or s_inodes_per_group in the superblock validator, returning -EINVAL so the mount fails before any block-group or inode I/O occurs.

Exploitation Scenario

An attacker with physical access to an edge-AI device — e.g., a sensor gateway or camera performing on-device inference that accepts an SD card for data logging or model updates — crafts an ext2 image with s_blocks_per_group or s_inodes_per_group set to zero, potentially disguising it as a legitimate firmware or model-update card. Inserting the card and triggering an auto-mount (at boot or hot-plug) causes get_ngroups() or get_itable_entry() to divide by zero during ext2_init_fs(), raising a UsageFault that Zephyr treats as fatal and reboots the device. Repeating the insertion lets the attacker force repeated crashes, disrupting availability of a safety- or operations-critical edge deployment without needing any credentials or network foothold.