CVE-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—