CVE-2024-26704

What it actually does

Double-free of filesystem blocks in ext4_move_extents due to moved_len not being updated on partial loop failure, allowing overlapped preallocated extents to be released twice and triggering zero-division in mb_update_avg_fragment_size when bb_free and bb_fragments become inconsistent.

Why it matters to the business

Local users on affected Linux systems can trigger kernel crashes or memory corruption during extent-moving operations, leading to denial of service and potential data integrity issues on ext4 filesystems; the issue has been fixed for over two years with no known active exploitation campaigns.

How an attack unfolds

An attacker with local access crafts a sequence of extent moves via the EXT4_IOC_MOVE_EXT ioctl that succeeds for some extents but fails before moved_len is updated; the resulting inconsistent preallocation state later causes double-free during release or trim, producing a kernel panic or corruption that can be leveraged for further attacks.

How to fix it

Upgrade the Linux kernel to a version containing commit b4fbb89d722cbb16beaaea234b7230faaaf68c71 or later; apply the fix that updates moved_len after each successful extent move and ensure preallocations are discarded correctly.

How to confirm the fix worked

Confirm the running kernel contains commit b4fbb89d722cbb16beaaea234b7230faaaf68c71; test that ext4_move_extents and subsequent trim operations no longer produce double-free or zero-division conditions under the previously failing scenarios.

Typical attack path

1. Obtain local unprivileged access to a system running an unpatched Linux kernel with ext4
2. Identify or create files allowing use of EXT4_IOC_MOVE_EXT to move extents
3. Trigger a partial failure in ext4_move_extents so that moved_len remains zero
4. Cause subsequent preallocation release or fstrim to execute the double-free path
5. Observe kernel panic or corruption for denial of service or attempt further exploitation

How to detect it

Review kernel logs for oops/panic messages referencing ext4_mb_release_inode_pa, ext4_process_freed_data, or division by zero in mb_update_avg_fragment_size; correlate with processes invoking extent-move ioctls on ext4 filesystems.

What your security team should do

• Prioritize kernel upgrades to the fixed commit on all systems using ext4
• Restrict unprivileged use of EXT4_IOC_MOVE_EXT where possible via capabilities or SELinux policies
• Monitor for kernel oops or panic logs related to ext4_mb_release_inode_pa and mb_update_avg_fragment_size
• Apply the fix even on systems without known active threat actor exploitation