linux-kernel - Re: [PATCH] ocfs2: zero-initialize recovery bitmap to prevent uninit-value in find_next

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dvgcsdqeqhryxx7gy4mq65m44wti3ruqdqe4h43npofm4wrryl@edfz4nrai3yl>
Date: Mon, 9 Feb 2026 19:01:57 +0100
From: Jan Kara <jack@...e.cz>
To: Daniel Hodges <git@...ielhodges.dev>
Cc: Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>, 
	Joseph Qi <joseph.qi@...ux.alibaba.com>, Jan Kara <jack@...e.cz>, ocfs2-devel@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, syzbot+7ea0b96c4ddb49fd1a70@...kaller.appspotmail.com, 
	stable@...r.kernel.org
Subject: Re: [PATCH] ocfs2: zero-initialize recovery bitmap to prevent
 uninit-value in find_next_bit

On Mon 09-02-26 11:13:47, Daniel Hodges wrote:
> ocfs2_add_recovery_chunk() allocates a bitmap buffer of sb->s_blocksize
> bytes using kmalloc() but only copies (ol_chunk_entries(sb) + 7) >> 3
> bytes into it from the on-disk quota chunk. When the number of chunk
> entries is not aligned to a long boundary (64 bits on 64-bit systems),
> find_next_bit() reads uninitialized memory from the trailing bytes of
> the last word in the bitmap.

OK, but AFAICS it does not impact the functionality in any way because we
properly use:

for_each_set_bit(bit, rchunk->rc_bitmap, ol_chunk_entries(sb))

so the uninitialized bits are actually never used. This would be good to
stress in the changelog. Since this isn't really a performance sensitive
code I agree with the fix to make the checker happy anyway but I wanted to
make sure... So feel free to add:

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

								Honza

> 
> Fix this by using kzalloc() to zero-initialize the entire bitmap
> allocation, ensuring that any bits beyond the copied region are
> clean zeros.
> 
> Reported-by: syzbot+7ea0b96c4ddb49fd1a70@...kaller.appspotmail.com
> Fixes: 2205363dce74 ("ocfs2: Implement quota recovery")
> Cc: stable@...r.kernel.org
> Signed-off-by: Daniel Hodges <git@...ielhodges.dev>
> ---
>  fs/ocfs2/quota_local.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/quota_local.c b/fs/ocfs2/quota_local.c
> index de7f12858729..bd3eb098097f 100644
> --- a/fs/ocfs2/quota_local.c
> +++ b/fs/ocfs2/quota_local.c
> @@ -302,7 +302,7 @@ static int ocfs2_add_recovery_chunk(struct super_block *sb,
>  	if (!rc)
>  		return -ENOMEM;
>  	rc->rc_chunk = chunk;
> -	rc->rc_bitmap = kmalloc(sb->s_blocksize, GFP_NOFS);
> +	rc->rc_bitmap = kzalloc(sb->s_blocksize, GFP_NOFS);
>  	if (!rc->rc_bitmap) {
>  		kfree(rc);
>  		return -ENOMEM;
> -- 
> 2.52.0
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR