[lvc-project] [PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Mikhail Dmitrichenko]

From: Hongbo Li <lihongbo22 at huawei.com>

Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
range_is_hole_in_parent()") is a patch backported directly from
mainline to 6.6, it does not free the path in the inline extents case.

The original patch in mainline does not have this problem because
the former commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
conversions") in 6.18-rc1 introduced scope-based auto-cleanup which
avoids this issue. Since some dependencies are missing and cannot
be directly backported, we choose to use a goto statement to avoid
the memory leak in inline extents case.

Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in range_is_hole_in_parent()")
Signed-off-by: Hongbo Li <lihongbo22 at huawei.com>
Reviewed-by: Qu Wenruo <wqu at suse.com>
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko at astralinux.ru>
---
This is a follow-up fix for the 6.6.y backport of the CVE-2026-23141 fix.
It was posted and reviewed in February, but was not sent to stable@, so
6.6.y still has the leak:
https://lore.kernel.org/all/20260227075219.2594937-1-lihongbo22@huawei.com/

 fs/btrfs/send.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 099b5a2e1156..7b19b1ea29fd 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6545,8 +6545,10 @@ 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;
+		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
+			ret = 0;
+			goto out;
+		}
 		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
 			search_start = extent_end;
 			goto next;
-- 
2.43.0