CVE-2025-70101: lwext4 1.0.0 Out-of-Bounds Read Denial of Service

Technical summary

The vulnerability resides in the ext4_ext_binsearch_idx function within src/ext4_extent.c of lwext4 1.0.0. The function performs a binary search over extent index entries to locate blocks in the ext4 extent tree. The flaw stems from insufficient validation of extent header fields before the search begins. Without proper bounds checking, the function computes invalid pointers during tree traversal, leading to out-of-bounds memory reads. Attackers exploit this by crafting ext4 filesystem images with malformed extent headers—fields that define the structure and bounds of index entries. When the library processes these images, the unchecked calculations cause memory access violations.

Business impact

The primary business impact is application unavailability. Any service or tool relying on lwext4 to mount or read ext4 filesystems will crash when encountering a malicious image. For embedded systems, IoT devices, backup tools, or recovery utilities that bundle lwext4, this creates a denial-of-service vector that can be exploited remotely if the filesystem is served over a network, or locally if an attacker can deliver a malicious disk image. Data confidentiality and integrity are not at direct risk; the concern is uptime and operational continuity.

Affected systems

gkostka lwext4 version 1.0.0 is confirmed vulnerable. Any application or embedded system that integrates this library—including but not limited to backup software, disk recovery tools, virtual machine hypervisors, embedded Linux systems with limited ext4 support, and IoT devices—is potentially at risk. The vulnerability is triggered only when the library actively processes a malicious ext4 filesystem, so passive systems or those that do not interact with untrusted filesystems have lower exposure.

Exploitability

Exploitation requires user interaction: a victim must open, mount, or process a crafted ext4 filesystem image using software built on lwext4. The attacker cannot trigger the vulnerability remotely without the user's involvement in loading the malicious image. No authentication or elevated privilege is required on the victim's part. The technical bar for crafting a malicious image is moderate—an attacker must understand ext4 extent structures well enough to inject invalid header values, but public filesystem format documentation and fuzzing tools make this feasible. The CVSS score of 6.5 reflects medium severity: network-accessible attack vector, low complexity, no privileges needed, but user interaction required and limited to denial of service.

Remediation

Upgrade lwext4 to a version released after 1.0.0 that includes validation hardening for extent header fields. Verify that the patched version includes bounds checking before extent index searches and validates header consistency. As an interim mitigation, restrict processing of ext4 filesystems to trusted sources only and avoid mounting or analyzing untrusted or user-supplied disk images in production environments.

Patch guidance

Check the gkostka lwext4 repository and release notes for versions beyond 1.0.0. The vendor should have released a patch that adds validation of extent header fields and bounds checks in the ext4_ext_binsearch_idx function. Verify the patch against the official vendor advisory before deployment. Test patched versions in a non-production environment to ensure compatibility with your application. If you maintain a fork or embedded copy of lwext4, apply the upstream fixes or implement equivalent validation logic.

Detection guidance

Monitor applications and systems using lwext4 for unexpected crashes or segmentation faults when processing filesystem images, particularly those sourced from external or untrusted origins. Implement input validation at the application layer: reject or isolate ext4 filesystems with malformed extent headers before passing them to lwext4. Use fuzzing and static analysis tools to test custom filesystem processing code. In network-facing services that handle filesystem uploads or analysis, rate-limit and quarantine suspicious uploads for further investigation.

Why prioritize this

Prioritize this vulnerability for patching in systems that process untrusted ext4 filesystems—backup utilities, recovery tools, and publicly accessible filesystem analysis services rank highest. Systems that only mount filesystems from controlled, trusted infrastructure may deprioritize relative to network-facing or user-facing applications. The medium CVSS score and user-interaction requirement lower urgency compared to unauthenticated remote code execution flaws, but the broad potential for denial of service across embedded and edge systems warrants timely remediation.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects a combination of factors: the attack vector is network-accessible (filesystem images can be transferred over the network), attack complexity is low (no special conditions needed beyond a malicious image), no privileges or authentication are required, and user interaction is required (the user must initiate processing). The impact is limited to availability (denial of service via crash); confidentiality and integrity are not compromised. This places the vulnerability in the medium range—more severe than information disclosure but less urgent than remote code execution.

Frequently asked questions