CVE-2025-70100: lwext4 Divide-by-Zero Denial of Service (MEDIUM)

Technical summary

The vulnerability resides in the ext4_block_set_lb_size function within src/ext4_blockdev.c of lwext4 version 1.0.0. During filesystem initialization, the function processes the logical block size field from an ext4 filesystem image without validating that the value is non-zero. When a malformed image with lb_size=0 is supplied, subsequent arithmetic operations that divide by lb_size trigger a divide-by-zero exception. Under sanitizer-instrumented builds (common in development and testing), this manifests as a Floating-Point Exception (FPE) signal. In production builds, the behavior depends on the runtime environment but typically results in process termination or undefined behavior. The vulnerability is classified as CWE-369 (Divide By Zero) and requires user interaction in the form of mounting or processing the malicious image.

Business impact

Organizations using lwext4 in their software stack face service interruption risk if untrusted or compromised filesystem images are processed. This affects embedded system manufacturers, forensic analysis tool developers, containerization platforms that support ext4, and any applications handling filesystem recovery or data access. The impact is primarily availability-focused: a malicious image can crash critical filesystem operations without requiring elevated privileges. In supply-chain scenarios, a compromised storage device or downloaded filesystem image could be weaponized to disrupt dependent services. The medium CVSS score reflects the local attack surface and user interaction requirement, but the simplicity of exploitation (a single crafted image) and the potential for widespread deployment in embedded contexts elevates practical risk.

Affected systems

lwext4 version 1.0.0 is confirmed affected. lwext4 is a portable, lightweight ext4 filesystem library commonly embedded in firmware, embedded Linux systems, bootloaders, and specialized applications where full kernel-level ext4 support is not available. The vulnerability affects any product or service that statically or dynamically links against this library version and processes untrusted ext4 filesystem images. Verify your bill of materials and dependency manifests to identify internal products using lwext4.

Exploitability

Exploitation is straightforward and requires no special privileges. An attacker must craft or modify an ext4 filesystem image to set the logical block size field to zero, then trigger the vulnerable code path by mounting the image or initiating image processing through the affected application. The local attack vector and lack of privilege requirements mean that any user with access to the application's input (e.g., via USB, network transfer, or shared filesystem) can trigger the crash. However, exploitation is limited by the requirement that the target application must actively process the malicious image—passive possession of the image does not trigger the vulnerability. This is not listed on CISA's KEV catalog, indicating no evidence of active exploitation in the wild at time of publication.

Remediation

Patch lwext4 to a version that includes input validation for the logical block size parameter. Contact gkostka (the maintainer) or check the project repository for available updates. The remediation should include bounds checking to ensure lb_size is not zero before any arithmetic operations. Until patching is possible, implement defense-in-depth controls: validate filesystem images before processing (e.g., cryptographic signatures or filesystem integrity checks), restrict which users can supply filesystem images, and run lwext4-dependent applications in isolated environments (containers, VMs, sandboxes) to contain crash impacts.

Patch guidance

Check the lwext4 project repository (https://github.com/gkostka/lwext4) for updates beyond version 1.0.0. Review release notes and commit history for fixes related to block size validation or divide-by-zero issues in ext4_block_set_lb_size. If using lwext4 as an embedded dependency, coordinate with your build and integration teams to pull in patched versions and perform regression testing on filesystem operations. Verify the patch in your testing environment using both benign and specially crafted ext4 images with zero block sizes to confirm the vulnerability is resolved.

Detection guidance

Monitor application logs for crashes or exceptions in lwext4 code paths, particularly FPE (SIGFPE) signals or segmentation faults during filesystem mount or image processing. Implement process monitoring to detect unexpected terminations of services that process filesystem images. In development and CI/CD environments, run lwext4 with sanitizers (ASan, UBSan) enabled to catch divide-by-zero and other undefined behavior early. If feasible, add filesystem image validation before lwext4 processing: verify the superblock structure, confirm block size is within valid ranges (typically 1024 to 65536 bytes), and reject images with suspicious or zero block sizes. Network-based detection is limited because the vulnerability requires local image processing, but monitor for unusual filesystem image uploads or modifications in your environment.

Why prioritize this

Prioritize based on your use of lwext4 in production systems. If lwext4 is embedded in firmware, bootloaders, or edge devices serving many customers, treat this as high-priority for coordinated patching and deployment. If lwext4 is used in isolated tools or non-critical applications, prioritize lower but do not defer indefinitely. The simplicity of exploitation and lack of privilege requirements favor quick remediation where lwext4 is exposed to user-supplied or untrusted content. The medium CVSS score should not lull teams into complacency; even medium-severity availability issues can have cascading business impacts in production environments.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects a vulnerability with high attack complexity (local only), no privilege escalation, no confidentiality or integrity impact, but high availability impact. The vector AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H indicates local attack vector, low attack complexity (minimal crafting required), no privilege requirement, user interaction (mounting the image), unscoped impact, and high availability impact. The score appropriately captures that the vulnerability is a denial-of-service with no data breach or system compromise potential. However, real-world risk may be higher if lwext4 processes images from untrusted sources or if the crash has cascading effects on dependent services.

Frequently asked questions