Re: [BUG] btrfs: oversized compressed disk_num_bytes is not rejected

[Qu Wenruo <wqu@suse.com>]

在 2026/11/16 03:07, Cheng Yongkang 写道:
> 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;
>    +	}

IIRC I didn't add that max extent size for both compressed (128K) and 
uncompressed (256M) because we might enlarge those values in the future.

But considering LZO is already rejecting based on MAX_COMPRESSED, I 
think it's time to add such tree-checker.

Please send out the tree-checker patch, not only checking against the 
max compressed size, but also uncompressed ones.

> 
> 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.

I prefer not to use u64 for length. With tree-checker it should be enough.

> 
> Thanks,
> Cheng Yongkang