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
