In February 2024, Linux kernel maintainers fixed a significant vulnerability tracked as CVE-2024-26590, affecting the EROFS (Enhanced Read-Only File System). This issue, discovered through the syzkaller fuzzer, could lead to a kernel crash and presents a potential vector for denial-of-service attacks. Below, we break down what went wrong, the technical details, and how the vulnerability was resolved. This article uses easy-to-grasp language and provides links and code to illustrate the problem.

What is EROFS?

EROFS (Enhanced Read-Only File System) is a modern Linux file system, widely used due to its high performance and efficient support for compressed files, especially on Android devices. EROFS supports multiple compression algorithms and allows them to be chosen per file (within the same filesystem image).

What’s the Bug (CVE-2024-26590)?

EROFS images store their supported compression algorithms in the superblock when mounted. Each file/inode within the EROFS could then specify which compression format it uses.

syzkaller fuzzed this logic by creating “malformed”/crafted EROFS images

- The global image claims to support only a subset of compression algorithms (via sbi->available_compr_algs).
- But, some files are marked as using unsupported or missing compression types, such as MicroLZMA, which aren’t correctly initialized by the kernel during the mount.

Impact

- The EROFS kernel code would assume the compressor/decompressor was available, and try to use it.
- If not present/built-in, this would cause a NULL pointer dereference and crash the entire kernel.

Exploit Details: How is it Triggered?

An attacker can craft a malicious EROFS image (for example, by hand, or with syzkaller) with metadata marking certain files as using a compressor not enabled in the superblock. The attack does not require special privileges if a target mounts this filesystem.

Here’s how the exploit unfolds

1. Attacker crafts a filesystem image which claims support for just LZ4 in the available_compr_algs superblock field.

The victim system (with CONFIG_EROFS_FS enabled, but without MicroLZMA support) mounts the image.

4. When the affected file is read, the kernel looks for a decompressor for MicroLZMA, finds none (leading to a NULL pointer), and crashes with a message like:

Below is a simplified mockup showing how the check was missing

// Before patch: 
int decompress(struct erofs_sb_info *sbi, struct inode *inode)
{
    if (inode->compression == MICRO_LZMA) {
        // No check if MICRO_LZMA is in sbi->available_compr_algs!
        return micro_lzma_decompress(...); // May NULL deref!
    }
    // ...
}

Mark a file’s compression field to MICRO_LZMA.

- Distribute/mount on a vulnerable kernel.

The Fix: Better Algorithm Validation

The kernel patch (see source commit) fixed two main issues:

Per-File Compression Validation:

Now, for every file access, the kernel cross-checks if the algorithm requested is REALLY present in the superblock’s allowed list.

Preset Bitmap Fix:

The check ensuring which compression algos are possible is now properly set, strengthening the EROFS configuration.

Patched Code Snippet

// After patch:
int decompress(struct erofs_sb_info *sbi, struct inode *inode)
{
    if (!(sbi->available_compr_algs & (1 << inode->compression))) {
        pr_err("Attempt to use unavailable compressor: %d\n", inode->compression);
        return -EINVAL; // Graceful failure, no crash!
    }
    // Safe to decompress now
    return do_decompression(...);
}

Original References

- Linux kernel commit fixing CVE-2024-26590
- syzkaller bug report
- EROFS Project
- CVE-2024-26590 at NVD

Affected versions: Linux kernels before the patch (merged in mid-Feb 2024).

- Who’s at risk: Systems that 1) enable EROFS, 2) mount untrusted/third-party images (think Android, cloud, embedded).
- Fix: Upgrade your kernel to a version including the fix. Disabling EROFS or not mounting untrusted images also mitigates the risk.

Conclusion

CVE-2024-26590 is a straightforward, but high-impact bug that shows how filesystem metadata inconsistencies can lead to kernel-level vulnerabilities. Always validate untrusted input, even in low-level system code. If you use EROFS, update your kernel as soon as possible!


*This is an exclusive, simplified write-up based on the original kernel sources and reports. For more technical deep-dives, consult the references above.*

Timeline

Published on: 02/22/2024 17:15:09 UTC
Last modified on: 03/18/2024 17:54:20 UTC