[BUG] btrfs: oversized compressed disk_num_bytes is not rejected

[Cheng Yongkang <teel4res@gmail.com>]

Hi David,

I hit a corner case with crafted images. It needs a compressed file
extent whose disk_num_bytes is far above what btrfs ever writes, so it
may not matter much in practice. I found two consequences of the same
missing check.

check_extent_data_item() only checks that disk_num_bytes is sector
aligned, and the zlib read path does not limit its input to
BTRFS_MAX_COMPRESSED the way lzo_decompress_bio() does. Both cases
below are on v7.3.

1) disk_num_bytes == 0x100000000

After mounting with rescue=all and reading the file,
btrfs_submit_compressed_read() stores em->disk_num_bytes in an
unsigned int compressed_len, which becomes 0. No folio is added, and
the zero-length bio hits the assertion in btrfs_submit_bbio() (seen
with CONFIG_BTRFS_ASSERT=y):

  assertion failed: IS_ALIGNED(logical, blocksize) &&
  IS_ALIGNED(length, blocksize) && length != 0, in fs/btrfs/bio.c:895
  (root=5 inode=257 logical=9437184 length=0)
  kernel BUG at fs/btrfs/bio.c:895!
   btrfs_submit_compressed_read
   btrfs_readahead

2) zlib extent with disk_num_bytes == 4 MiB

With num_bytes == ram_bytes == 0x100002000 and a zlib stream that
inflates to about 4.3 GB, reading the page at file offset 0xFFFFF000
makes bvec_offset + bv_len wrap to 0 in the u32 arithmetic of
btrfs_decompress_buf2page(). copy_len is then computed from the
wrapped value, and memcpy() reads past the 4 KiB zlib workspace
buffer:

  BUG: KASAN: slab-out-of-bounds in btrfs_decompress_buf2page+0x3e0/0x650
  Read of size 4096 at addr ffff8881114049f8 by task kworker/u8:2/41
   __asan_memcpy
   btrfs_decompress_buf2page
   zlib_decompress_bio
   end_bbio_compressed_read
   btrfs_check_read_bio
  Allocated by task 9375:
   zlib_alloc_workspace
  The buggy address is located 2552 bytes inside of
   allocated 4096-byte region [ffff888111404000, ffff888111405000)

The 4 MiB compressed bio only fit into its 32 vecs when the pages were
physically contiguous, so before reading I filled 16 pipes with 1 MiB
each. Without that the read failed with -EIO or SIGBUS instead.

Both paths are unchanged in next-20261113. zstd no longer calls
btrfs_decompress_buf2page() there, but zlib and lzo still do.

Compression and encoded writes never create a compressed extent larger
than BTRFS_MAX_COMPRESSED, so the tree checker could reject such an
extent for all compression types, which stops both cases:

  +	if (unlikely(btrfs_file_extent_compression(leaf, fi) != BTRFS_COMPRESS_NONE &&
  +		     btrfs_file_extent_disk_num_bytes(leaf, fi) > BTRFS_MAX_COMPRESSED)) {
  +		file_extent_err(leaf, slot,
  +	"invalid disk_num_bytes for compressed file extent, have %llu expect <= %u",
  +				btrfs_file_extent_disk_num_bytes(leaf, fi),
  +				BTRFS_MAX_COMPRESSED);
  +		return -EUCLEAN;
  +	}

With this change the tree checker reports the leaf of the first image
as corrupt and the mount fails with -EIO, and normal zstd, zlib and
lzo files still read back correctly. I have not run the second image
on it; its disk_num_bytes is 4 MiB, above the limit. Separately, the
u32 arithmetic in btrfs_decompress_buf2page() could be done in u64 as
hardening. I can send patches if you want them.

Thanks,
Cheng Yongkang