lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <v2ih4phv2qncxqstanziraevrru6i4bg7gbwdgu5poqke323tt@rj2mqgiiaxn3>
Date: Wed, 5 Nov 2025 12:19:32 +0100
From: Jan Kara <jack@...e.cz>
To: sunyongjian1@...wei.com
Cc: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	tytso@....edu, jack@...e.cz, yangerkun@...wei.com, yi.zhang@...wei.com, 
	libaokun1@...wei.com, chengzhihao1@...wei.com
Subject: Re: [PATCH 1/2] ext4: fix incorrect group number assertion in
 mb_check_buddy for exhausted preallocations

On Wed 05-11-25 15:42:49, Yongjian Sun wrote:
> From: Yongjian Sun <sunyongjian1@...wei.com>
> 
> When the MB_CHECK_ASSERT macro is enabled, an assertion failure can
> occur in __mb_check_buddy when checking preallocated blocks (pa) in
> a block group:
> 
> Assertion failure in mb_free_blocks() : "groupnr == e4b->bd_group"
> 
> This happens when a pa at the very end of a block group (e.g.,
> pa_pstart=32765, pa_len=3 in a group of 32768 blocks) becomes
> exhausted - its pa_pstart is advanced by pa_len to 32768, which
> lies in the next block group. If this exhausted pa (with pa_len == 0)
> is still in the bb_prealloc_list during the buddy check, the assertion
> incorrectly flags it as belonging to the wrong group. A possible
> sequence is as follows:
> 
> ext4_mb_new_blocks
>   ext4_mb_release_context
>     pa->pa_pstart += EXT4_C2B(sbi, ac->ac_b_ex.fe_len)
>     pa->pa_len -= ac->ac_b_ex.fe_len
> 
> 	                 __mb_check_buddy
>                            for each pa in group
>                              ext4_get_group_no_and_offset
>                              MB_CHECK_ASSERT(groupnr == e4b->bd_group)
> 
> To fix this, we modify the check to skip block group validation for
> exhausted preallocations (where pa_len == 0). Such entries are in a
> transitional state and will be removed from the list soon, so they
> should not trigger an assertion. This change prevents the false
> positive while maintaining the integrity of the checks for active
> allocations.
> 
> Fixes: c9de560ded61f ("ext4: Add multi block allocator for ext4")
> Signed-off-by: Yongjian Sun <sunyongjian1@...wei.com>
> Reviewed-by: Baokun Li <libaokun1@...wei.com>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@...e.cz>

								Honza

> ---
>  fs/ext4/mballoc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 9087183602e4..194a9f995c36 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -768,6 +768,8 @@ static void __mb_check_buddy(struct ext4_buddy *e4b, char *file,
>  		ext4_group_t groupnr;
>  		struct ext4_prealloc_space *pa;
>  		pa = list_entry(cur, struct ext4_prealloc_space, pa_group_list);
> +		if (!pa->pa_len)
> +			continue;
>  		ext4_get_group_no_and_offset(sb, pa->pa_pstart, &groupnr, &k);
>  		MB_CHECK_ASSERT(groupnr == e4b->bd_group);
>  		for (i = 0; i < pa->pa_len; i++)
> -- 
> 2.39.2
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ