[PATCH 0/2] btrfs: hardening against radix tree conflicts on 32bit systems

[Qu Wenruo <wqu@suse.com>]

Inspired by a recent patch touching btrfs_ioctl_subvol_sync() function,
it turns out that we have a very rare (I'd even call it unpractical) but
still real (one can even craft one image) problem, that on 32-bit
systems, we always truncate the subvolid down to 32bit unsigned long.

This means the following two valid subvolume trees will get the same
index:

  Subvolume 257 (0x101) and subvolume 4294967553 (0x100000101)

It should really be very rare, as we have other limits like anon_dev,
which should hit way before subvolumeid limits.
But one can craft an image with only above two subvolumes, and on 32bit
systems only one subvolume can be reached.

Address the situation by:

- Do not insert data reloc tree into fs_roots_radix
  As we will reject subvolume ids > ULONG_MAX on 32 bit systems, we
  don't want to insert data reloc tree into that radix tree in the first
  place.

- Reject subvolume ids > ULONG_MAX
  For 64 bits this will become an no-op.

  For 32 bits, most subvolumes should still have their ids <= ULONG_MAX.

  For crafted images, subvolumes ids larger than ULONG_MAX will be
  rejected with a rate-limited error message every time such subvolume
  is going to be inserted.

  This can lead to some transaction abort, e.g. createing a snapshot
  whose id is too large.

  But I don't have better solution than rejecting them.


Qu Wenruo (2):
  btrfs: do not insert the data reloc tree into fs_roots_radix
  btrfs: reject subvolume ids that do not fit into unsigned long

 fs/btrfs/disk-io.c | 64 +++++++++++++++++++++++++++++++++++++++-------
 fs/btrfs/disk-io.h | 19 ++++++++++++++
 fs/btrfs/ioctl.c   |  2 +-
 3 files changed, 75 insertions(+), 10 deletions(-)

-- 
2.56.0