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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox