public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
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


             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