[SECURITY] Out-of-bounds read in btrfs driver (btrfs_read_extent_reg, fs/btrfs/inode.c)

[Alessandro Schino]

Hello,
I'm reporting an out-of-bounds read I found in U-Boot's btrfs filesystem
driver while reviewing the source, and confirmed with a working
AddressSanitizer reproducer on a sandbox build.
Summary
In btrfs_read_extent_reg() (fs/btrfs/inode.c), the compressed-extent path
uses file_extent_offset — a value read directly from the on-disk extent
item — as an offset into the decompression buffer, without validating it
against the buffer size (ram_bytes). A crafted btrfs image with a large
file_extent_offset makes the subsequent memcpy read far past the end of the
buffer.
The two ASSERT() guards earlier in the function do not prevent this:
U-Boot's assert() is compiled out when _DEBUG is unset (the production
default), and the asserts do not compare file_extent_offset against
ram_bytes anyway. U-Boot also does not import btrfs's semantic
tree-checker, so the field is not validated at leaf-load time.
Impact
Out-of-bounds read reachable from an untrusted btrfs image (e.g. removable
media). The out-of-bounds bytes are copied into the read destination
(information disclosure); depending on layout the read can also fault
(denial of service during boot). As this runs in the bootloader, the usual
runtime mitigations are absent.
Reproduction and full details
I confirmed the crash on a sandbox build with CONFIG_ASAN: loading a
crafted image triggers an AddressSanitizer READ overflow in memcpy, called
from btrfs_read_extent_reg. I tested against commit 6741b0dfb41 .
A complete technical writeup, the PoC generator, and the AddressSanitizer
output are available here:
https://github.com/inkman97/U-Boot-btrfs-oob
The writeup also includes a suggested bounds check and a broader
recommendation to validate btrfs_file_extent_item fields at leaf-load time.
I'm following coordinated disclosure and happy to work with you on timing
and testing. Please let me know your preferred channel if you'd rather I
share the material privately.

Best regards,
Alessandro Schino