Re: [PATCH] btrfs: reject global extent/csum roots without offset 0 when extent_tree_v2 is off

[David Sterba <dsterba@suse.cz>]

On Mon, Mar 02, 2026 at 07:02:02PM +0800, ZhengYuan Huang wrote:
> Without EXTENT_TREE_V2, btrfs_extent_root() and btrfs_csum_root() always
> look up the global roots at offset 0. A crafted image can provide only
> non-zero offsets for the extent/csum global roots, so the offset 0 lookup
> returns NULL and later leads to a NULL dereference
> (e.g. in backup_super_roots()).
> 
> Fix this by detecting this at mount time: when loading extent/csum
> global roots without EXTENT_TREE_V2, require that an offset 0 root item
> exists, otherwise fail the mount with -EUCLEAN.
> 
> Tested with a crafted image that has only non-zero offset global roots,
> which triggers the KASAN null-ptr-deref in backup_super_roots() before
> the fix, and fails the mount with -EUCLEAN after the fix.
> 
> Fixes: f7238e509404 ("btrfs: add support for multiple global roots")
> Cc: stable@vger.kernel.org # v5.18+
> Signed-off-by: ZhengYuan Huang <gality369@gmail.com>

You've cut the changelog here but the rest of the information should be
also there, perhaps in a more condensed form. You can add other things
under the "---" line in case it's relevant for the patch submission but
not for the long term git history.

> ---
[...]

> CPU: 0 UID: 0 PID: 34 Comm: kworker/u8:1 Tainted: G           OE       6.18.0 #1 PREEMPT(voluntary)

> Reproduction (v6.18, x86_64, KASAN)
> ===================================
> 1. Download the crafted image (tested with Linux v6.18 + KASAN):

This seems to be testing 6.18 and probably the exact release, not the
updated stable branch which is 6.18.16 right now. It's OK to test on
older versions but please use the latest available one as the fixes get
backported.

As Filipe said this has been fixed and the patch is in for-next, not yet
in master or any stable tree. For fuzzing or crafted images it makes
more sense to test on recent development branches. If you don't track
each subsystem individually you should use linux-next, where the btrfs
for-next branch gets merged and the updates happen every other day.

I'll queue the fixes for some of the upcoming -rc. Thanks.