CVE-2024-49960

What it actually does

Use-after-free in ext4_fill_super when a mount failure after ext4_stop_mmpd triggers ext4_handle_error that re-arms the s_err_report timer, leaving it active before kfree(sbi) and allowing the freed timer structure to be referenced by del_timer_sync or the timer callback.

Why it matters to the business

Linux systems using ext4 may experience kernel crashes or potential local privilege escalation during failed filesystem mounts, leading to service outages on servers, containers, and embedded devices until kernels are updated; prevalence across the Linux ecosystem increases exposure for organizations relying on ext4 storage.

How an attack unfolds

An attacker with local access triggers repeated ext4 mount failures that exercise the error path through ext4_stop_mmpd and ext4_handle_error, leaving the s_err_report timer active; the freed timer memory is then reused to corrupt kernel structures and achieve code execution, consistent with patterns seen in Linux kernel exploitation campaigns by espionage and financially motivated actors.

How to fix it

Upgrade to a fixed kernel version such as 5.10.237 or apply the commit 7aac0c17a8cdf4a3236991c1e60435c6a984076c; for Rocky Linux 8 update mailman to 3:2.1.29-11.module+el8.4.0+539+54f8785b; rebuild and reboot systems with the patched kernel; avoid mounting untrusted ext4 images until updated.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking the presence of the timer cancel after ext4_stop_mmpd in ext4_fill_super; attempt controlled failed mounts in a test environment and verify no ODEBUG warnings occur; review dmesg for timer-related use-after-free reports on unpatched systems.

Typical attack path

1. Obtain local user access on a system using an affected ext4 kernel
2. Craft conditions that cause ext4 mount to fail after the MMPD stop step
3. Trigger error handling that re-arms the s_err_report timer
4. Free the superblock while the timer remains queued
5. Reuse the freed timer memory to corrupt kernel state and escalate privileges

How to detect it

Search kernel logs and dmesg for ODEBUG warnings or timer use-after-free messages referencing ext4_fill_super or s_err_report; inspect auditd and syslog entries around mount failures for unusual ext4 error handling sequences; correlate with any local privilege escalation attempts on systems running vulnerable kernels.

What your security team should do

• Prioritize kernel updates on all ext4-using systems within standard change windows given the local attack vector and high CVSS
• Restrict unprivileged users from mounting arbitrary filesystems until patches are deployed
• Monitor for new stable kernel releases and test the fix in staging environments before broad rollout
• Review logs for any prior ODEBUG or timer warnings that could indicate attempted exploitation