Description

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix race between ordered extent completion and 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).

However by not locking the target extent range for the whole duration of
the fiemap call we can race with an ordered extent. This happens like
this:

1) The fiemap task finishes processing a file extent item that covers
the file range [512K, 1M[, and that file extent item is the last item
in the leaf currently being processed;

2) And ordered extent for the file range [768K, 2M[, in COW mode,
completes (btrfs_finish_one_ordered()) and the file extent item
covering the range [512K, 1M[ is trimmed to cover the range
[512K, 768K[ and then a new file extent item for the range [768K, 2M[
is inserted in the inode's subvolume tree;

3) The fiemap task calls fiemap_next_leaf_item(), which then calls
btrfs_next_leaf() to find the next leaf / item. This finds that the
the next key following the one we previously processed (its type is
BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding
to the new file extent item inserted by the ordered extent, which has
a type of BTRFS...

Classification

CVE ID: CVE-2024-26794

Affected Products

Vendor: Linux

Product: Linux

Exploit Prediction Scoring System (EPSS)

EPSS Score: 0.05% (probability of being exploited)

EPSS Percentile: 17.83% (scored less or equal to compared to others)

EPSS Date: 2025-02-04 (when was this score calculated)

References

https://git.kernel.org/stable/c/d43f8e58f10a44df8c08e7f7076f3288352cd168
https://git.kernel.org/stable/c/31d07a757c6d3430e03cc22799921569999b9a12
https://git.kernel.org/stable/c/a1a4a9ca77f143c00fce69c1239887ff8b813bec

Timeline