CVE-2024-50015 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
ext4: dax: fix overflowing extents beyond inode size when partially writing
The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:
dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M
fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?
Fix the problem by truncating extents if the written length is smaller than expected.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 03/22/2026
The vulnerability CVE-2024-50015 affects the Linux kernel's ext4 file system implementation, specifically within the direct access (DAX) functionality. This issue stems from improper handling of extent management during partial write operations when signal handling interrupts the process. The flaw occurs in the dax_iomap_rw() function which processes write operations by mapping blocks and copying user data in iterative rounds. When a process is terminated by a signal during this operation, the system fails to properly account for the partial data written, leading to incorrect inode size calculations.
The technical implementation involves the dax_iomap_rw() function executing multiple iterations where it maps written blocks and copies user data to those blocks. During the first iteration, the function allocates and maps extents from 0 to 2MB and copies 2MB of data. In the second iteration, it continues mapping from 2MB onwards but encounters a fatal signal before completing the full write operation. The system calculates the written length as 2MB but fails to properly truncate or adjust the extent mapping, resulting in an inode size that reflects only the partial write while the actual extent allocation exceeds the expected file size. This creates a discrepancy where the file system's internal accounting shows an inode size of 2MB while the actual allocated extents cover 4MB, causing fsck to report inconsistencies.
The operational impact of this vulnerability extends beyond simple file system corruption, as it can lead to data integrity issues and potential system instability. When fsck encounters the mismatch between inode size and actual extent allocation, it generates error messages indicating that the inode size does not match expected values. This inconsistency can cause file system repair operations to fail or produce incorrect results, potentially leading to data loss or accessibility issues. The vulnerability is particularly concerning in environments where DAX functionality is heavily utilized for high-performance storage operations, as it undermines the reliability of direct memory access mechanisms that are critical for applications requiring low-latency file system operations. This issue directly relates to CWE-129 and CWE-131 in the Common Weakness Enumeration, which address improper input validation and incorrect calculation of buffer sizes.
The fix implemented addresses this vulnerability by truncating extents when the written length is smaller than expected, ensuring that the extent mapping aligns properly with the actual data written. This solution prevents the accumulation of partial write data that would otherwise cause the inode size to exceed the actual file content. The mitigation approach specifically targets the dax_iomap_rw() function's handling of signal interruptions and ensures proper cleanup of extent allocations when processes are terminated prematurely. This remediation aligns with ATT&CK techniques related to privilege escalation and resource exhaustion, as it prevents potential attackers from exploiting file system inconsistencies to gain unauthorized access or cause denial of service conditions. The fix ensures that the ext4 file system maintains proper consistency between inode metadata and actual extent allocations, thereby preserving data integrity and preventing fsck failures that could compromise system reliability.