btrfs: only search for left_info if there is no right_info in try_merge_free_space
authorJosef Bacik <josef@toxicpanda.com>
Mon, 27 Jul 2020 14:28:05 +0000 (10:28 -0400)
committerDavid Sterba <dsterba@suse.com>
Mon, 10 Aug 2020 16:58:07 +0000 (18:58 +0200)
commitbf53d4687b8f3f6b752f091eb85f62369a515dfd
tree04296d7e67bedb3416a1775e5825ae20a25cd08c
parent1e6e238c3002ea3611465ce5f32777ddd6a40126
btrfs: only search for left_info if there is no right_info in try_merge_free_space

In try_to_merge_free_space we attempt to find entries to the left and
right of the entry we are adding to see if they can be merged.  We
search for an entry past our current info (saved into right_info), and
then if right_info exists and it has a rb_prev() we save the rb_prev()
into left_info.

However there's a slight problem in the case that we have a right_info,
but no entry previous to that entry.  At that point we will search for
an entry just before the info we're attempting to insert.  This will
simply find right_info again, and assign it to left_info, making them
both the same pointer.

Now if right_info _can_ be merged with the range we're inserting, we'll
add it to the info and free right_info.  However further down we'll
access left_info, which was right_info, and thus get a use-after-free.

Fix this by only searching for the left entry if we don't find a right
entry at all.

The CVE referenced had a specially crafted file system that could
trigger this use-after-free. However with the tree checker improvements
we no longer trigger the conditions for the UAF.  But the original
conditions still apply, hence this fix.

Reference: CVE-2019-19448
Fixes: 963030817060 ("Btrfs: use hybrid extents+bitmap rb tree for free space")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/free-space-cache.c