CVE-2024-53234 - RCE Risk in Linux EROFS Filesystem via Crafted Images — Deep Dive and Exploit Insight

Table of contents

[Patch and Mitigation](#patch)

- [Read More / References](#references)


Intro: What is CVE-2024-53234?

A new Linux kernel vulnerability has been uncovered and patched, impacting the EROFS filesystem: CVE-2024-53234. The issue lives deep in how the kernel handles certain metadata clusters, and if properly exploited, it can lead to kernel WARNINGs, info leaks, or potential denial-of-service situations via a specially-crafted filesystem image.


Background: EROFS and the Flaw

EROFS stands for Enhanced Read-Only File System, which is popular in mobile and embedded Linux systems due to its decompressed-on-demand feature. The problem here is how the kernel handles "logical clusters" (lclusters) during file mapping operations, particularly with an ancient or specially crafted EROFS image.

Generally, NONHEAD lclusters are expected to have a non-zero delta[1] parameter.

- Malicious or old mkfs tools could build filesystems where delta[1]== in NONHEAD lclusters—unexpected by the code. When this happens, user tools querying mapped file extents (FIEMAP ioctl) can cause the kernel to miscalculate decompressed region sizes.
- Additionally, a cluster bit setting (lclusterbits > 14) can further worsen things due to impossible index calculation, possibly panicking or making the kernel misbehave.


How the Vulnerability Works

When a process exposes the EROFS filesystem and a crafted image is mounted, any call to the FIEMAP ioctl (common for introspecting file layouts) can trigger this flaw. Previously, the code would "bail out" (exit without error) upon detecting delta[1]==. However, this left the decompressed size incorrect, leading to possible memory mismanagement and exposure of sensitive data.

Here is the vulnerable snippet (simplified for clarity)

// erofs/inode.c, before patch
if (!delta[1]) {      // if delta[1] ==  for NONHEAD lcluster
    DBG_BUGON(1);     // triggers a kernel bug warning
    return -EFSCORRUPTED;
}
decompressed_length = delta[1] << cluster_bits;
// further FIEMAP logic...

The kernel warning looked like this

WARNING in iomap_fiemap+x73b/x9b fs/iomap/fiemap.c:80

Exploit Details and Proof-of-Concept

An attacker can produce an intentionally malformed EROFS image (using a custom mkfs or low-level binary tool), specifying delta[1]== for a NONHEAD lcluster. When this image is mounted, even a regular non-root user can run fiemap (or ls, or any tool that scans file extents) and trigger the bug.

`bash

filefrag -v /mnt/crafted_image/foo.txt

Info leak: With memory mismanagement, fiemap could leak some stale memory.

- Wider reach: Embedded and Android devices using EROFS are at specific risk if untrusted images are handled.


Patch and Mitigation

The fix (see commit here) gracefully handles the case:
- If delta[1] == , it now treats it as delta[1] = 1 — a safe fallback closely mimicking legacy mkfs behavior, avoiding panics or miscalculations.

Pseudocode from the fix

if (lclusterbits > 14) {
    return -EINVAL;    // reject illegal cluster bits
}
if (!delta[1]) {
    delta[1] = 1;      // safe workaround for legacy case
}

Mitigation recommendations

- Update your kernel to a version with this commit merged (mainline 6.10+, or 6.1 stable series after June 2024).

Harden systems by restricting FIEMAP or mount permissions for untrusted users.


## Read More / References

- Original Patch: [erofs: handle NONHEAD !delta[1] lclusters gracefully](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=564ce2b2d12e)
- Kernel FIEMAP documentation: linux/Documentation/filesystems/fiemap.txt
- EROFS homepage
- Linux EROFS source code

Summary

CVE-2024-53234 is a subtle but important vulnerability in the Linux kernel’s EROFS code. By mounting a crafted filesystem image, users could trigger kernel warnings or more dangerous misbehavior. The fix is out—update your systems and never mount untrusted images.

Timeline

Published on: 12/27/2024 14:15:31 UTC
Last modified on: 05/04/2025 13:00:45 UTC