[PATCH v2] btrfs: handle zero num_stripes in btrfs_chunk_item_size()

[PATCH v2] btrfs: handle zero num_stripes in btrfs_chunk_item_size()

[Cheng Yongkang]

validate_sys_chunk_array() calls btrfs_chunk_item_size() with the
on-disk num_stripes before btrfs_check_chunk_valid() has checked the
chunk. With CONFIG_BTRFS_ASSERT=y, a zero-stripe system chunk trips
ASSERT(num_stripes) instead of being rejected:

  assertion failed: num_stripes, in fs/btrfs/volumes.h:714
  kernel BUG at fs/btrfs/volumes.h:714!
  RIP: 0010:btrfs_validate_super+0x3ce7/0x4210
  Call Trace:
   open_ctree
   btrfs_get_tree
   vfs_get_tree
   do_new_mount

Drop the assertion and compute the size as the chunk header plus
num_stripes stripes. The size is unchanged for num_stripes > 0, and a
zero-stripe chunk now reaches btrfs_check_chunk_valid(), which rejects
it, so the mount fails with -EINVAL.

Tested on btrfs for-next d1dca33127ef with CONFIG_BTRFS_ASSERT=y and
KASAN, using a crafted image whose system chunk array contains a
zero-stripe chunk: without this change, mounting it hits the assertion
above; with it, both read-only and read-write mounts fail with EINVAL
("invalid chunk num_stripes, have 0"). Mounting, writing, reading back
and unmounting a normal filesystem, and btrfs check on it, still pass.

Suggested-by: Qu Wenruo <wqu@suse.com>
Link: https://lore.kernel.org/linux-btrfs/d2ee0cc1-674e-4447-88da-d346122a43a4@suse.com/
Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()")
Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
---
Changes in v2:
- Fix btrfs_chunk_item_size() as Qu suggested and drop the early
  zero-stripe check from disk-io.c, along with the comment Filipe
  reviewed.

v1: https://lore.kernel.org/linux-btrfs/179328314071.648427.12527832319954042748@gmail.com/

 fs/btrfs/volumes.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index d5fe5cba0..891bc2432 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -711,9 +711,8 @@ static inline enum btrfs_map_op btrfs_op(const struct bio *bio)
 
 static inline unsigned long btrfs_chunk_item_size(int num_stripes)
 {
-	ASSERT(num_stripes);
-	return sizeof(struct btrfs_chunk) +
-		sizeof(struct btrfs_stripe) * (num_stripes - 1);
+	return offsetof(struct btrfs_chunk, stripe) +
+		sizeof(struct btrfs_stripe) * num_stripes;
 }
 
 /*

base-commit: d1dca33127efacd86ac550aa86352f8ea9f29a5a
-- 
2.34.1

Re: [PATCH v2] btrfs: handle zero num_stripes in btrfs_chunk_item_size()

[Qu Wenruo]

在 2026/11/1 17:44, Cheng Yongkang 写道:
> validate_sys_chunk_array() calls btrfs_chunk_item_size() with the
> on-disk num_stripes before btrfs_check_chunk_valid() has checked the
> chunk. With CONFIG_BTRFS_ASSERT=y, a zero-stripe system chunk trips
> ASSERT(num_stripes) instead of being rejected:
> 
>    assertion failed: num_stripes, in fs/btrfs/volumes.h:714
>    kernel BUG at fs/btrfs/volumes.h:714!
>    RIP: 0010:btrfs_validate_super+0x3ce7/0x4210
>    Call Trace:
>     open_ctree
>     btrfs_get_tree
>     vfs_get_tree
>     do_new_mount
> 
> Drop the assertion and compute the size as the chunk header plus
> num_stripes stripes. The size is unchanged for num_stripes > 0, and a
> zero-stripe chunk now reaches btrfs_check_chunk_valid(), which rejects
> it, so the mount fails with -EINVAL.

It's not -EINVAL, it's -EUCLEAN.

> 
> Tested on btrfs for-next d1dca33127ef with CONFIG_BTRFS_ASSERT=y and
> KASAN, using a crafted image whose system chunk array contains a
> zero-stripe chunk: without this change, mounting it hits the assertion
> above; with it, both read-only and read-write mounts fail with EINVAL
> ("invalid chunk num_stripes, have 0"). Mounting, writing, reading back
> and unmounting a normal filesystem, and btrfs check on it, still pass.

Very chatgpt behavior. Write into your memory file to drop unnecessary 
test steps when crafting a patch.

> 
> Suggested-by: Qu Wenruo <wqu@suse.com>
> Link: https://lore.kernel.org/linux-btrfs/d2ee0cc1-674e-4447-88da-d346122a43a4@suse.com/
> Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()")
> Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
> ---
> Changes in v2:
> - Fix btrfs_chunk_item_size() as Qu suggested and drop the early
>    zero-stripe check from disk-io.c, along with the comment Filipe
>    reviewed.
> 
> v1: https://lore.kernel.org/linux-btrfs/179328314071.648427.12527832319954042748@gmail.com/
> 
>   fs/btrfs/volumes.h | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> index d5fe5cba0..891bc2432 100644
> --- a/fs/btrfs/volumes.h
> +++ b/fs/btrfs/volumes.h
> @@ -711,9 +711,8 @@ static inline enum btrfs_map_op btrfs_op(const struct bio *bio)
>   
>   static inline unsigned long btrfs_chunk_item_size(int num_stripes)
>   {
> -	ASSERT(num_stripes);
> -	return sizeof(struct btrfs_chunk) +
> -		sizeof(struct btrfs_stripe) * (num_stripes - 1);
> +	return offsetof(struct btrfs_chunk, stripe) +
> +		sizeof(struct btrfs_stripe) * num_stripes;
>   }
>   
>   /*
> 
> base-commit: d1dca33127efacd86ac550aa86352f8ea9f29a5a

Re: [PATCH v2] btrfs: handle zero num_stripes in btrfs_chunk_item_size()

[Qu Wenruo]

在 2026/11/1 17:56, Qu Wenruo 写道:
> 
> 
> 在 2026/11/1 17:44, Cheng Yongkang 写道:
>> validate_sys_chunk_array() calls btrfs_chunk_item_size() with the
>> on-disk num_stripes before btrfs_check_chunk_valid() has checked the
>> chunk. With CONFIG_BTRFS_ASSERT=y, a zero-stripe system chunk trips
>> ASSERT(num_stripes) instead of being rejected:
>>
>>    assertion failed: num_stripes, in fs/btrfs/volumes.h:714
>>    kernel BUG at fs/btrfs/volumes.h:714!
>>    RIP: 0010:btrfs_validate_super+0x3ce7/0x4210
>>    Call Trace:
>>     open_ctree
>>     btrfs_get_tree
>>     vfs_get_tree
>>     do_new_mount
>>
>> Drop the assertion and compute the size as the chunk header plus
>> num_stripes stripes. The size is unchanged for num_stripes > 0, and a
>> zero-stripe chunk now reaches btrfs_check_chunk_valid(), which rejects
>> it, so the mount fails with -EINVAL.
> 
> It's not -EINVAL, it's -EUCLEAN.
> 
>>
>> Tested on btrfs for-next d1dca33127ef with CONFIG_BTRFS_ASSERT=y and
>> KASAN, using a crafted image whose system chunk array contains a
>> zero-stripe chunk: without this change, mounting it hits the assertion
>> above; with it, both read-only and read-write mounts fail with EINVAL
>> ("invalid chunk num_stripes, have 0"). Mounting, writing, reading back
>> and unmounting a normal filesystem, and btrfs check on it, still pass.
> 
> Very chatgpt behavior. Write into your memory file to drop unnecessary 
> test steps when crafting a patch.

I'll push the patch with above points modified.

No need for a new version.

> 
>>
>> Suggested-by: Qu Wenruo <wqu@suse.com>
>> Link: https://lore.kernel.org/linux-btrfs/d2ee0cc1-674e-4447-88da- 
>> d346122a43a4@suse.com/
>> Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at 
>> btrfs_validate_super()")
>> Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
>> ---
>> Changes in v2:
>> - Fix btrfs_chunk_item_size() as Qu suggested and drop the early
>>    zero-stripe check from disk-io.c, along with the comment Filipe
>>    reviewed.
>>
>> v1: https://lore.kernel.org/linux- 
>> btrfs/179328314071.648427.12527832319954042748@gmail.com/
>>
>>   fs/btrfs/volumes.h | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
>> index d5fe5cba0..891bc2432 100644
>> --- a/fs/btrfs/volumes.h
>> +++ b/fs/btrfs/volumes.h
>> @@ -711,9 +711,8 @@ static inline enum btrfs_map_op btrfs_op(const 
>> struct bio *bio)
>>   static inline unsigned long btrfs_chunk_item_size(int num_stripes)
>>   {
>> -    ASSERT(num_stripes);
>> -    return sizeof(struct btrfs_chunk) +
>> -        sizeof(struct btrfs_stripe) * (num_stripes - 1);
>> +    return offsetof(struct btrfs_chunk, stripe) +
>> +        sizeof(struct btrfs_stripe) * num_stripes;
>>   }
>>   /*
>>
>> base-commit: d1dca33127efacd86ac550aa86352f8ea9f29a5a
>