From: syzbot <syzbot+7960178e777909060224@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] ocfs2: add check for free bits before allocation in ocfs2_move_extent()
Date: Sun, 04 Jan 2026 04:26:22 -0800 [thread overview]
Message-ID: <695a5c6e.050a0220.a1b6.038c.GAE@google.com> (raw)
In-Reply-To: <69441a92.a70a0220.207337.00e4.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ocfs2: add check for free bits before allocation in ocfs2_move_extent()
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add a check to verify the group descriptor has enough free bits before
attempting allocation in ocfs2_move_extent(). This prevents a kernel
BUG_ON crash in ocfs2_block_group_set_bits() when the move_extents ioctl
is called on a crafted or corrupted filesystem.
The existing validation in ocfs2_validate_gd_self() only checks static
metadata consistency (bg_free_bits_count <= bg_bits) when the descriptor
is first read from disk. However, during move_extents operations,
multiple allocations can exhaust the free bits count below the requested
allocation size, triggering BUG_ON(le16_to_cpu(bg->bg_free_bits_count)
num_bits).
The debug trace shows the issue clearly:
- Block group 32 validated with bg_free_bits_count=427
- Repeated allocations decreased count: 427 -> 171 -> 43 -> ... -> 1
- Final request for 2 bits with only 1 available triggers BUG_ON
By adding an early check in ocfs2_move_extent() right after
ocfs2_find_victim_alloc_group(), we return -ENOSPC gracefully instead of
crashing the kernel. This also avoids unnecessary work in
ocfs2_probe_alloc_group() and __ocfs2_move_extent() when the allocation
will fail.
Reported-by: syzbot+7960178e777909060224@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7960178e777909060224
Link: https://lore.kernel.org/all/20251231115801.293726-1-kartikey406@gmail.com/T/ [v1]
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Fixed missing '<' in commit message (Joseph)
- Moved check right after ocfs2_find_victim_alloc_group() to fail
early and avoid unnecessary work (Joseph)
---
fs/ocfs2/move_extents.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c
index 99637e34d9da..c037fb34b1e3 100644
--- a/fs/ocfs2/move_extents.c
+++ b/fs/ocfs2/move_extents.c
@@ -662,6 +662,12 @@ static int ocfs2_move_extent(struct ocfs2_move_extents_context *context,
goto out_commit;
}
+ gd = (struct ocfs2_group_desc *)gd_bh->b_data;
+ if (le16_to_cpu(gd->bg_free_bits_count) < len) {
+ ret = -ENOSPC;
+ goto out_commit;
+ }
+
/*
* probe the victim cluster group to find a proper
* region to fit wanted movement, it even will perform
@@ -682,7 +688,6 @@ static int ocfs2_move_extent(struct ocfs2_move_extents_context *context,
goto out_commit;
}
- gd = (struct ocfs2_group_desc *)gd_bh->b_data;
ret = ocfs2_alloc_dinode_update_counts(gb_inode, handle, gb_bh, len,
le16_to_cpu(gd->bg_chain));
if (ret) {
--
2.43.0
prev parent reply other threads:[~2026-01-04 12:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 15:15 [syzbot] [ocfs2?] kernel BUG in ocfs2_move_extents syzbot
2025-12-23 20:31 ` syzbot
2025-12-31 5:05 ` Forwarded: [PATCH] ocfs2: add debug printk to trace block group validation path syzbot
2025-12-31 7:51 ` Forwarded: [PATCH] ocfs2: add check for free bits before allocation in ocfs2_move_extent() syzbot
2025-12-31 7:52 ` syzbot
2026-01-04 11:49 ` syzbot
2026-01-04 12:26 ` syzbot [this message]
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=695a5c6e.050a0220.a1b6.038c.GAE@google.com \
--to=syzbot+7960178e777909060224@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.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.