From: Daniel Hodges <git@danielhodges.dev>
To: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Jan Kara <jack@suse.cz>,
ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
Daniel Hodges <git@danielhodges.dev>,
syzbot+7ea0b96c4ddb49fd1a70@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: [PATCH] ocfs2: zero-initialize recovery bitmap to prevent uninit-value in find_next_bit
Date: Mon, 9 Feb 2026 11:13:47 -0500 [thread overview]
Message-ID: <20260209161347.30400-1-git@danielhodges.dev> (raw)
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.
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@syzkaller.appspotmail.com
Fixes: 2205363dce74 ("ocfs2: Implement quota recovery")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Hodges <git@danielhodges.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
next reply other threads:[~2026-02-09 16:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 16:13 Daniel Hodges [this message]
2026-02-09 18:01 ` [PATCH] ocfs2: zero-initialize recovery bitmap to prevent uninit-value in find_next_bit Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260209161347.30400-1-git@danielhodges.dev \
--to=git@danielhodges.dev \
--cc=jack@suse.cz \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=syzbot+7ea0b96c4ddb49fd1a70@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.