CVE-2024-26590

What it actually does

EROFS file system fails to validate per-inode compression algorithm against the superblock bitmap of available algorithms, allowing an unsupported type to reach a missing decompressor and trigger kernel NULL pointer dereference.

Why it matters to the business

Systems using EROFS-compressed images can experience local denial-of-service crashes; widespread kernel update is required across servers, containers, and embedded devices.

How an attack unfolds

An attacker crafts an EROFS image that marks an inode with an algorithm absent from sbi->available_compr_algs, then causes the image to be mounted or accessed on a kernel lacking the corresponding decompressor module; the unchecked request dereferences a NULL function pointer.

How to fix it

Upgrade to a kernel containing commit 47467e04816cb297905c0f09bc2d11ef865942d9 or later; rebuild with all required EROFS compression algorithms enabled or ensure the superblock bitmap is correctly set.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit, test mounting of previously crashing crafted images, and verify no NULL dereference occurs.

Typical attack path

1. Create or obtain a malicious EROFS filesystem image with inconsistent compression algorithm metadata
2. Place the image on a system that mounts EROFS volumes
3. Trigger mount or file access operations on the crafted image
4. Kernel dereferences NULL decompressor pointer and crashes

How to detect it

Monitor kernel logs for EROFS-related NULL pointer dereference BUG messages and unexpected mount failures on EROFS volumes; review audit logs for recent EROFS mounts from untrusted sources.

What your security team should do

• Apply the fixed kernel version immediately on all EROFS-using systems
• Audit boot and container images for EROFS usage and schedule staged rollouts
• Add kernel crash and EROFS mount failure alerts to monitoring