CVE-2024-27080: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-27080

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range. This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this: generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated---

AI Analysis

Technical Summary

CVE-2024-27080 is a race condition vulnerability in the Linux kernel's Btrfs filesystem implementation, specifically affecting the fiemap ioctl interface used to map file extents. The vulnerability arises from a recent change that removed locking of the entire target extent range during fiemap calls to avoid deadlocks when the fiemap buffer is memory-mapped to the same file. This change introduced a race where delalloc (delayed allocation) ranges in file holes may be missed during extent detection. The fiemap interface iterates over cloned leaves of the inode's subvolume tree to identify file extents and holes. However, if a delalloc range is flushed and its ordered extent completes during this iteration, it disappears from the cloned leaf. Consequently, fiemap incorrectly reports a hole where data actually exists in delalloc state. This can mislead user-space applications relying on fiemap to detect sparse file regions, such as the cp utility with the --sparse option in coreutils versions prior to 9.0. In such cases, copying a file with delalloc data in holes may result in data loss because the destination file will omit these data regions. The race is triggered when fiemap is called without the FIEMAP_FLAG_SYNC flag and the delalloc range is flushed concurrently. This issue was sporadically reproducible with filesystem tests (fstests generic/094). While the vulnerability does not directly allow code execution or privilege escalation, it can cause silent data corruption or loss in applications that depend on accurate extent mapping. No known exploits are reported in the wild, and the flaw was introduced by a recent commit aimed at fixing deadlocks. The patch involves restoring proper locking or synchronization to ensure delalloc ranges are correctly detected during fiemap calls.

Potential Impact

For European organizations, the primary impact of CVE-2024-27080 is the risk of silent data loss or corruption in systems using the Btrfs filesystem on Linux, particularly when applications rely on fiemap for sparse file handling. This can affect backup systems, file servers, and data processing pipelines that use cp or similar tools with sparse file support. Data integrity issues may lead to operational disruptions, loss of critical data, or compliance violations under data protection regulations such as GDPR if data loss affects personal or sensitive information. Organizations with large-scale Linux deployments using Btrfs, especially in data centers, cloud infrastructure, or enterprise storage solutions, are at risk. The vulnerability does not enable remote code execution or privilege escalation, so the threat is limited to data integrity rather than system compromise. However, unnoticed data loss can have severe business consequences, including downtime, recovery costs, and reputational damage. The sporadic nature of the race condition means the impact may be intermittent and hard to detect without thorough testing or monitoring.

Mitigation Recommendations

1. Apply the official Linux kernel patches that fix this race condition as soon as they become available to ensure fiemap correctly detects delalloc ranges. 2. Avoid using fiemap without the FIEMAP_FLAG_SYNC flag on Btrfs filesystems until patched, as the race occurs in asynchronous fiemap calls. 3. For critical data, consider disabling sparse file copying features (e.g., avoid using cp --sparse) or use alternative tools that do not rely on fiemap for extent detection. 4. Implement rigorous data integrity verification and backup validation processes to detect silent data loss early. 5. Monitor filesystem behavior and test critical file operations with updated fstests or similar tools to identify extent mapping inconsistencies. 6. Educate system administrators and developers about this subtle race condition to avoid assumptions about fiemap reliability on affected kernel versions. 7. Where possible, use filesystems other than Btrfs for workloads requiring guaranteed sparse file accuracy until the fix is deployed. 8. In environments with memory-mapped file operations, review usage patterns that may trigger this race and adjust accordingly.