CVE-2024-49884

What it actually does

Use-after-free in ext4_split_extent_at when ext4_find_extent returns an error such as -ENOMEM or -EIO, causing the original path pointer to be freed while later code still dereferences it for ext4_ext_dirty or ext4_ext_show_leaf operations during extent splitting and unwritten extent handling.

Why it matters to the business

Linux systems using the ext4 filesystem may experience kernel crashes, memory corruption, or local privilege escalation under write-heavy workloads or storage errors, increasing downtime and security risk especially on servers and embedded devices with large ext4 deployments.

How an attack unfolds

A local attacker performs file operations that invoke extent mapping and splitting; an induced allocation failure in ext4_find_extent during leaf creation frees the path, after which error-handling code reuses the dangling pointer, leading to slab use-after-free that can be leveraged for kernel code execution.

How to fix it

Update the Linux kernel to a version containing commit 393a46f60ea4f249dc9d496d4eb2d542f5e11ade or later; apply the corresponding package updates for affected distributions such as Rocky Linux nodejs-nodemon 1.18.3-1 or nodejs-packaging 17-3.

How to confirm the fix worked

Verify the running kernel contains the fix commit or is newer than the vulnerable version; reproduce the original KASAN trace with a crafted extent workload and confirm absence of use-after-free; scan dmesg and kernel logs for references to ext4_split_extent_at.

Typical attack path

1. Trigger ext4 extent operations via writes or fallocate on a file
2. Force memory allocation failure inside ext4_find_extent during ext4_split_extent_at
3. Reuse the now-freed path pointer in ext4_ext_dirty or ext4_ext_show_leaf
4. Exploit resulting slab corruption for privilege escalation or denial of service

How to detect it

Search kernel logs and dmesg for KASAN reports mentioning ext4_split_extent_at, ext4_find_extent, or slab-use-after-free during writepage activity; correlate with task names like kworker and allocation failures in extent code.

What your security team should do

• Prioritize kernel updates on all ext4-based production systems before the CISA-style remediation windows if applicable
• Enable KASAN or similar memory debugging in test environments to validate the patch
• Monitor for ext4 writepage errors and unusual allocation failures as potential triggers
• Restrict untrusted local code execution until patches are deployed