CVE-2025-70099: NULL Pointer Dereference in lwext4 Directory Parsing (Denial of Service)

Technical summary

CVE-2025-70099 is a NULL pointer dereference in the ext4_dir_en_get_name_len function located in include/ext4_dir.h of lwext4 1.0.0. During directory iteration, the function fails to validate that a directory entry pointer is non-NULL before dereferencing it to access the name_len field. When processing a specially crafted EXT4 filesystem image containing malformed directory entries, this validation gap leads to a segmentation fault. The vulnerability stems from the 2016-era codebase architecture and affects the directory parsing logic.

Business impact

Organizations using lwext4 (a lightweight EXT4 filesystem library) face availability risks. Any application embedding lwext4 that processes untrusted filesystem images—such as disk imaging tools, container runtimes, forensic platforms, or embedded storage managers—could be crashed by a malicious image. This creates a denial-of-service vector that could interrupt critical workflows, disrupt automated batch processing, or be weaponized in multi-stage attacks. The impact is particularly acute in cloud environments or edge devices where lwext4 may be used in storage orchestration or recovery tooling.

Affected systems

lwext4 version 1.0.0 and any application or service that directly embeds or links against this library version are affected. Specific vendor products are not listed in current advisories, suggesting the vulnerability affects a broad ecosystem of open-source and proprietary tools that have integrated lwext4. Organizations should audit their supply chain for lwext4 dependencies, particularly in embedded systems, container images, disk utilities, and storage platforms. Versions after 1.0.0 may or may not contain the fix; consult the lwext4 project repository for confirmation.

Exploitability

Exploitability is straightforward but requires delivery of a crafted filesystem image. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects network accessibility and low attack complexity. An attacker needs only to supply a malformed EXT4 image to trigger the crash—no authentication, user interaction, or local access is required. In practice, exploitability depends on exposure: applications that accept filesystem images from untrusted sources (e.g., user uploads, network shares, container images) face immediate risk. Isolated systems that only process filesystem images from trusted internal sources face lower risk.

Remediation

Immediate action: identify all applications and services in your environment that depend on lwext4 1.0.0 or equivalent versions. Contact the library maintainers or the projects embedding lwext4 to obtain patched versions. As of the current advisory, a specific patched version number is not confirmed; verify with the lwext4 project repository or the relevant vendor. In the interim, restrict filesystem image processing to validated and scanned sources where possible, and consider implementing input validation wrappers around EXT4 parsing operations. Monitor for upstream patches and plan deployment within your change management cycle.

Patch guidance

Begin by determining which software components in your environment use lwext4. Check the lwext4 project repository (https://github.com/gkostka/lwext4) for patches released after this advisory. If patched versions are available, prioritize deployment to systems that process untrusted or user-supplied filesystem images. For embedded or containerized deployments, rebuild and redeploy affected images with the patched library. If a patched lwext4 version is unavailable or delays are expected, implement application-level safeguards: validate filesystem metadata before parsing, run parsing operations in sandboxed processes with minimal privileges, and monitor for segmentation faults in logging and telemetry. Coordinate patching timelines with downstream projects that may be waiting for updates.

Detection guidance

Monitor application logs and system coredumps for segmentation faults (SIGSEGV) occurring in lwext4 directory parsing functions or the ext4_dir_en_get_name_len function. Enable detailed logging on any storage or filesystem processing tools that use lwext4. Track failed filesystem mount or parsing attempts, especially when processing images from external or untrusted sources. Network-based detection is limited; focus on host-based signals: process crashes, abnormal termination codes, and memory violation exceptions tied to EXT4 operations. If forensic capabilities are available, capture and analyze crash dumps for stack traces indicating the vulnerable code path.

Why prioritize this

This vulnerability merits HIGH priority (CVSS 7.5) due to several factors: (1) Low barrier to exploitation—any application can be crashed by a malformed image; (2) Wide potential blast radius—lwext4 is a general-purpose library used across embedded systems, containers, and storage tools; (3) Denial-of-service impact in automated or critical workflows can cascade; (4) The 2016-era codebase suggests extended deployment lifetime in legacy and embedded systems. However, impact is limited to availability; confidentiality and integrity are unaffected. Prioritize patching systems exposed to untrusted filesystem images. Systems processing only internal, validated images can follow a standard maintenance cadence.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a HIGH severity: network-accessible (AV:N), low attack complexity (AC:L), no privileges or user interaction required (PR:N, UI:N), unavailable scope (S:U), and high availability impact (A:H). No confidentiality (C:N) or integrity (I:N) impact occurs. The score is appropriate for a denial-of-service vulnerability in a library with broad reach. However, practical risk depends on deployment: a crashed parsing service in a fault-tolerant architecture may have lower real-world impact than a single-threaded embedded application. Adjust prioritization based on your application's role and resilience profile.

Frequently asked questions