CVE-2024-49983

What it actually does

Double-free in ext4 extent replay code caused by pointer aliasing between ppath and path during ext4_force_split_extent_at, allowing use-after-free when kfree is called on the same path object twice after ext4_find_extent nulls the pointer.

Why it matters to the business

Potential kernel memory corruption on systems using ext4 with journal replay of crafted extents, leading to crashes, data corruption, or local privilege escalation; low immediate urgency due to absence from KEV and stable low EPSS but relevant for organizations running affected Linux kernels in storage or database workloads.

How an attack unfolds

An attacker crafts a malicious ext4 filesystem image containing specific extent structures that trigger ext4_ext_replay_update_ex during journal recovery; the double-free occurs when ext4_find_extent frees the path and the subsequent kfree re-frees it, enabling memory manipulation. Generic Linux kernel threat actors have targeted similar use-after-free and out-of-bounds issues in recent campaigns.

How to fix it

Update the Linux kernel to a version containing commit 8c26d9e53e5fbacda0732a577e97c5a5b7882aaf or later; for Rocky Linux 8 apply the listed fixed package versions for postgresql, pgaudit, and postgres-decoderbufs after kernel update; rebuild and reboot systems using ext4.

How to confirm the fix worked

Verify the running kernel contains commit 8c26d9e53e5fbacda0732a577e97c5a5b7882aaf via uname or git describe; test ext4 journal replay on crafted images to confirm no double-free occurs; scan for the vulnerable ext4_ext_replay_update_ex function signature in kernel sources.

Typical attack path

1. Prepare malicious ext4 filesystem image with crafted extent metadata
2. Trigger mount or fsck that initiates journal replay
3. Invoke ext4_ext_replay_update_ex during replay
4. Trigger double-free via ext4_force_split_extent_at and ext4_find_extent
5. Exploit resulting use-after-free for memory corruption or code execution

How to detect it

Search kernel logs for repeated ext4 extent replay errors or oops messages around ext4_ext_replay_update_ex; inspect crash dumps for double kfree patterns on path structures; monitor for unexpected ext4 journal recovery activity on production volumes.

What your security team should do

• Prioritize kernel upgrades on ext4-heavy systems within standard patch cycles
• Monitor EPSS trend and any new exploit maturity reports
• Restrict untrusted filesystem images from being mounted or recovered
• Enable kernel hardening features such as KASAN in test environments for future validation