CVE: CVE-2024-27080

Descrizione: “The Linux kernel has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap, we recently stopped locking the target extent range for the entire fiemap call, 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 unlikely to be useful in practice but may be triggered by fuzz testing (e.g., syzbot). However, this introduced a race that causes us to miss delalloc ranges for file regions that are currently holes. Consequently, the caller of fiemap will not be aware of data for some file regions. This can be quite serious for some use cases, particularly in coreutils versions before 9.0, where cp used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file, to preserve holes (see the documentation for its –sparse command line option). This means if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, effectively a data loss issue. 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 misled 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 “

Vettore di attacco

Riferimenti esterni

• https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50
• https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3
• https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf

Prodotti interessati

• Linux – Linux
• Linux – Linux

Relazioni con altri prodotti

Produttore:Linux
Prodotto: Linux
Anno: 2024
CWE:
CVSS: 0.0

Ulteriori risorse disponibili

• Vulnerabilità scoperte nello stesso anno (2024)