CVE-2024-26704 in Linux
Summary
by MITRE • 04/03/2024
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double-free of blocks due to wrong extents moved_len
In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations.
If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero.
Therefore, update move_len after each extent move to avoid the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/03/2025
The vulnerability identified as CVE-2024-26704 represents a critical double-free condition within the ext4 filesystem implementation of the Linux kernel. This flaw manifests in the ext4_move_extents() function where improper handling of the moved_len variable leads to cascading memory management issues that can compromise system stability and potentially enable privilege escalation attacks. The vulnerability stems from a fundamental logic error in how the function tracks successful extent movements and manages preallocated block releases.
The technical flaw occurs when the ext4_move_extents() function processes a loop of extent moves where some extents may be successfully moved while others fail to complete. The moved_len variable, which should be incremented after each successful extent move, remains at zero when the loop exits prematurely due to failures in subsequent moves. This condition creates a dangerous scenario where preallocated extents that overlap with the moved extents are not properly accounted for in the cleanup process. The original implementation only discards preallocations when moved_len is non-zero, creating a path where overlapping preallocated blocks can be freed twice through different code paths in ext4_mb_release_inode_pa() and ext4_process_freed_data().
This double-free condition directly impacts the filesystem's block management subsystem by causing the bb_free counter to be incremented twice while the bb_fragments counter remains at zero, leading to a division by zero error in the mb_update_avg_fragment_size() function during trim operations. The mathematical inconsistency created by this scenario can trigger kernel panics or system crashes, effectively creating a denial of service vulnerability that affects the entire filesystem subsystem. The vulnerability is particularly concerning because it can be triggered through normal filesystem operations involving extent movement, making it exploitable in both legitimate and malicious usage scenarios.
The operational impact of this vulnerability extends beyond simple system instability to potential privilege escalation opportunities within the kernel space. According to CWE-415, this represents an improper free condition that can lead to memory corruption, while the ATT&CK framework categorizes this as a kernel exploitation technique that could be leveraged for privilege escalation. The vulnerability affects systems running Linux kernels with ext4 filesystem support, particularly those utilizing the EXT4_IOC_MOVE_EXT ioctl command for extent management operations. Organizations should prioritize patching this vulnerability as it can be triggered through normal filesystem operations and represents a significant risk to system availability and data integrity.
Mitigation strategies should focus on immediate kernel updates to address the specific code path in ext4_move_extents() where moved_len is not properly updated after each extent move. System administrators should implement monitoring for filesystem trim operations that might trigger the division by zero condition, while also ensuring that filesystem maintenance operations are performed with appropriate access controls. The fix requires updating the moved_len variable after each successful extent move operation to ensure proper preallocation cleanup and prevent the double-free scenario that leads to the zero-division error in the block management subsystem.