Re: [PATCH 5.10 004/161] btrfs: send: check for inline extents in range_is_hole_in_parent()

Greg Kroah-Hartman
2026-02-05T14:06:29Z

On Thu, Feb 05, 2026 at 02:51:18PM +0100, David Sterba wrote:
> On Wed, Feb 04, 2026 at 07:28:42PM +0100, Ben Hutchings wrote:
> > On Wed, 2026-02-04 at 15:37 +0100, Greg Kroah-Hartman wrote:
> > > 5.10-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Qu Wenruo <wqu@suse.com>
> > >
> > > [ Upstream commit 08b096c1372cd69627f4f559fb47c9fb67a52b39 ]
> > >
> > > Before accessing the disk_bytenr field of a file extent item we need
> > > to check if we are dealing with an inline extent.
> > > This is because for inline extents their data starts at the offset of
> > > the disk_bytenr field. So accessing the disk_bytenr
> > > means we are accessing inline data or in case the inline data is less
> > > than 8 bytes we can actually cause an invalid
> > > memory access if this inline extent item is the first item in the leaf
> > > or access metadata from other items.
> > >
> > > Fixes: 82bfb2e7b645 ("Btrfs: incremental send, fix unnecessary hole writes for sparse files")
> > > Reviewed-by: Filipe Manana <fdmanana@suse.com>
> > > Signed-off-by: Qu Wenruo <wqu@suse.com>
> > > Reviewed-by: David Sterba <dsterba@suse.com>
> > > Signed-off-by: David Sterba <dsterba@suse.com>
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > ---
> > > fs/btrfs/send.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> > > index d86b4d13cae48..f144171ed6b7e 100644
> > > --- a/fs/btrfs/send.c
> > > +++ b/fs/btrfs/send.c
> > > @@ -5892,6 +5892,8 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
> > > extent_end = btrfs_file_extent_end(path);
> > > if (extent_end <= start)
> > > goto next;
> > > + if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
> > > + return 0;
> >
> > This will leak path, unless (at least) commits 4c74a32ad323 "btrfs:
> > DEFINE_FREE for struct btrfs_path" and 4ca6f24a52c4 "btrfs: more trivial
> > BTRFS_PATH_AUTO_FREE conversions" are also backported.
> >
> > That could be avoided by using { ret = 0; goto out; } here instead of
> > simply returning.
>
> Right, the original patch assumes the automatic cleanup of btrfs_path, so
> for anything below it needs to be updated as you say.

Thanks for the review, I'll go drop this from all of the queues now.

greg k-h