CVE-2023-54121 — btrfs: fix incorrect splitting in btrfs_drop_extent_map_range

Affected: Linux

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

btrfs: fix incorrect splitting in btrfs_drop_extent_map_range

In production we were seeing a variety of WARN_ON()'s in the extent_map code, specifically in btrfs_drop_extent_map_range() when we have to call add_extent_mapping() for our second split.

Consider the following extent map layout

PINNED [0 16K) [32K, 48K)

and then we call btrfs_drop_extent_map_range for [0, 36K), with skip_pinned == true. The initial loop will have

start = 0 end = 36K len = 36K

we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code

start = em_end; if (end != (u64)-1) len = start + len - em_end;

em_end here is 16K, so now the values are

start = 16K len = 16K + 36K - 16K = 36K

len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this

split->start = start + len; split->len = em_end - (start + len);

In this case we have

em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K

and now we have an invalid extent_map in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations.

We don't actually need len in this…

Most recent entries from all

CVE-2023-54121 — btrfs: fix incorrect splitting in btrfs_drop_extent_map_range