Re: [PATCH v3] btrfs: validate data reloc tree file extent item members in tree-checker
From: Qu Wenruo
Date: Mon Apr 27 2026 - 20:45:13 EST
在 2026/4/28 07:45, Qu Wenruo 写道:
在 2026/4/28 05:54, Teng Liu 写道:
get_new_location() uses BUG_ON() to crash the kernel if the file extent
item it looks up has any of offset, compression, encryption, or
other_encoding set. The data reloc inode is only written by relocation's
own paths -- insert_prealloc_file_extent() and
insert_ordered_extent_file_extent() -- which always leave those four
fields at 0 (the data reloc inode is created with BTRFS_INODE_NOCOMPRESS,
and encryption/other_encoding are reserved-and-zero). Observing a
non-zero value therefore means the leaf decoded from disk does not match
what the kernel wrote, i.e. on-disk corruption. A malformed image can
reach this code via balance and panic the kernel.
Move the validation into tree-checker's check_extent_data_item(), where
the constraint is enforced when the leaf is read off disk rather than
after relocation has already started. The data reloc tree has a fixed
root id (BTRFS_DATA_RELOC_TREE_OBJECTID) recorded in the extent buffer
header, so check_extent_data_item() has all the information it needs to
apply this check on its own. Report violations via file_extent_err() and
print the four offending values.
In get_new_location() replace the BUG_ON() with an ASSERT().
The caller in replace_file_extents() already handles non-zero returns from
get_new_location() by breaking out of the loop without aborting the
transaction, so no caller changes are needed.
Suggested-by: Qu Wenruo <wqu@xxxxxxxx>
Suggested-by: David Sterba <dsterba@xxxxxxxx>
Reported-by: syzbot+3e20d8f3d41bac5dc9a2@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes: https://syzkaller.appspot.com/bug?extid=3e20d8f3d41bac5dc9a2
Signed-off-by: Teng Liu <27rabbitlt@xxxxxxxxx>
Reviewed-by: Qu Wenruo <wqu@xxxxxxxx>
And merged.
Unfortunately this tree-checker got triggered during btrfs/061 runs at write-time tree-checker, with arm64 64K page size.
The offending file extent is as the following:
[ 536.885066] item 69 key (258 EXTENT_DATA 4063232) itemoff 12400 itemsize 53
[ 536.885067] generation 28 type 1
[ 536.885067] extent data disk bytenr 10512723968 nr 36864
[ 536.885068] extent data offset 24576 nr 12288 ram 36864
[ 536.885069] extent compression 0
Note the offset is not zero, and the type is 1 which means it's a regular file extent.
So the check is causing false alerts.
Now the patch is reverted, and I'll spend more time digging into the case.
Thanks,
Qu
Thanks,
Qu
---
Changes in v3:
- Move the corruption check from relocation.c into tree-checker's
check_extent_data_item(), per Qu and David. The data reloc tree's
fixed objectid is recorded in the extent buffer header, so the
check has all the context it needs at read time.
- Use file_extent_err() and print offset/compression/encryption/
other_encoding values, per Qu.
- Replace the BUG_ON in get_new_location() with ASSERT() rather than
-EUCLEAN, per David.
Changes in v2:
- Pair the -EUCLEAN return with btrfs_print_leaf() and btrfs_err() so
the offending leaf is dumped to dmesg, per Qu's review of v1.
- Expand the changelog to argue why non-zero
compression/encryption/other_encoding in the data reloc inode imply
on-disk corruption.
fs/btrfs/relocation.c | 8 ++++----
fs/btrfs/tree-checker.c | 21 +++++++++++++++++++++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 1c42c5180bdd..527d4dbfe31c 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -835,10 +835,10 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr,
fi = btrfs_item_ptr(leaf, path->slots[0],
struct btrfs_file_extent_item);
- BUG_ON(btrfs_file_extent_offset(leaf, fi) ||
- btrfs_file_extent_compression(leaf, fi) ||
- btrfs_file_extent_encryption(leaf, fi) ||
- btrfs_file_extent_other_encoding(leaf, fi));
+ ASSERT(!btrfs_file_extent_offset(leaf, fi) &&
+ !btrfs_file_extent_compression(leaf, fi) &&
+ !btrfs_file_extent_encryption(leaf, fi) &&
+ !btrfs_file_extent_other_encoding(leaf, fi));
if (num_bytes != btrfs_file_extent_disk_num_bytes(leaf, fi))
return -EINVAL;
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index 1f15d0793a9c..e4864f7a471e 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -296,6 +296,27 @@ static int check_extent_data_item(struct extent_buffer *leaf,
return 0;
}
+ /*
+ * For the data reloc tree, file extent items are written by
+ * relocation's own paths, which always leave offset, compression,
+ * encryption and other_encoding as 0. Any non-zero value here means
+ * the leaf decoded from disk does not match what the kernel wrote,
+ * i.e. on-disk corruption.
+ */
+ if (unlikely(btrfs_header_owner(leaf) == BTRFS_DATA_RELOC_TREE_OBJECTID &&
+ (btrfs_file_extent_offset(leaf, fi) ||
+ btrfs_file_extent_compression(leaf, fi) ||
+ btrfs_file_extent_encryption(leaf, fi) ||
+ btrfs_file_extent_other_encoding(leaf, fi)))) {
+ file_extent_err(leaf, slot,
+"invalid members for data reloc tree, offset=%llu compress=%u encryption=%u other_encoding=%u",
+ btrfs_file_extent_offset(leaf, fi),
+ btrfs_file_extent_compression(leaf, fi),
+ btrfs_file_extent_encryption(leaf, fi),
+ btrfs_file_extent_other_encoding(leaf, fi));
+ return -EUCLEAN;
+ }
+
/* Regular or preallocated extent has fixed item size */
if (unlikely(item_size != sizeof(*fi))) {
file_extent_err(leaf, slot,