CVE-2024-40972

What it actually does

The ext4_xattr_set_entry function allocates new extended attribute inodes while holding a buffer lock on the external xattr block, nesting allocation locks under the buffer lock and enabling deadlock on corrupted filesystems where structures like the quota file reference xattr blocks as data blocks.

Why it matters to the business

Linux systems using the ext4 filesystem may experience unexpected hangs or crashes during normal file operations on damaged storage, leading to unplanned downtime and potential data access loss until the system is restarted or the filesystem is repaired.

How an attack unfolds

An attacker with local access or the ability to supply a corrupted ext4 image triggers xattr set operations that invoke the flawed allocation path, causing the kernel to deadlock when buffer and allocation locks are acquired in the wrong order.

How to fix it

Update the Linux kernel to a version containing commit 0752e7fb549d90c33b4d4186f11cfd25a556d1dd or later; rebuild and reboot affected systems with the patched kernel.

How to confirm the fix worked

Verify the running kernel contains commit 0752e7fb549d90c33b4d4186f11cfd25a556d1dd by checking the kernel version or git log; attempt to reproduce the deadlock scenario on a test corrupted filesystem to confirm the hang no longer occurs.

Typical attack path

1. Obtain or induce a corrupted ext4 filesystem image containing xattr blocks referenced as data blocks
2. Perform xattr set operations via user-space tools or applications that invoke ext4_xattr_set_entry
3. Trigger the nested locking condition that leads to deadlock

How to detect it

Search kernel logs for deadlock messages or hung task warnings involving ext4_xattr_set_entry or buffer lock contention; inspect system call traces for xattr operations on ext4 volumes immediately preceding a hang.

What your security team should do

• Prioritize kernel updates on all production ext4 systems within standard change windows
• Monitor for ext4 filesystem corruption reports and schedule fsck runs where indicated
• Review and test backup/restore procedures to ensure rapid recovery from kernel hangs