[syzbot] [ocfs2?] divide error in ocfs2_block_group_fill (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 9b332cece987 Merge tag 'nfsd-6.18-1' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=107b85e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c2d7b4143707d3a0
dashboard link: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9b332cec.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/512c0375bad7/vmlinux-9b332cec.xz
kernel image: https://storage.googleapis.com/syzbot-assets/458c8c31cc7b/bzImage-9b332cec.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com

loop0: detected capacity change from 0 to 32768
=======================================================
WARNING: The mand mount option has been deprecated and
and is ignored by this kernel. Remove the mand
option from the mount to silence this warning.
=======================================================
ocfs2: Mounting device (7,0) on (node local, slot 0) with ordered data mode.
Oops: divide error: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386
Code: 34 1a 49 81 c6 50 01 00 00 45 0f b7 3f 49 83 c5 02 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 eb 03 00 00 44 89 f8 31 d2 <66> 41 f7 75 00 0f b7 d8 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0
RSP: 0018:ffffc9000fd362a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000100000
RDX: 0000000000000000 RSI: 00000000000010fe RDI: 00000000000010ff
RBP: ffffc9000fd363a8 R08: 00313050554f5247 R09: 00313050554f5247
R10: dffffc0000000000 R11: ffffed100a449001 R12: dffffc0000000000
R13: ffff8880334dc2c2 R14: ffff888052248150 R15: 0000000000000000
FS: 00007f73479876c0(0000) GS:ffff88808d301000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000000 CR3: 000000004280a000 CR4: 0000000000352ef0
Call Trace:
<TASK>
ocfs2_block_group_alloc_discontig fs/ocfs2/suballoc.c:634 [inline]
ocfs2_block_group_alloc fs/ocfs2/suballoc.c:703 [inline]
ocfs2_reserve_suballoc_bits+0x20a6/0x4640 fs/ocfs2/suballoc.c:834
ocfs2_reserve_new_metadata_blocks+0x403/0x940 fs/ocfs2/suballoc.c:984
ocfs2_expand_inline_dir fs/ocfs2/dir.c:2845 [inline]
ocfs2_extend_dir+0xc76/0x4870 fs/ocfs2/dir.c:3207
ocfs2_prepare_dir_for_insert+0x2fe8/0x5450 fs/ocfs2/dir.c:4312
ocfs2_mknod+0x819/0x2050 fs/ocfs2/namei.c:297
ocfs2_create+0x1a5/0x440 fs/ocfs2/namei.c:676
vfs_create+0x24e/0x400 fs/namei.c:3493
do_mknodat+0x3c6/0x4d0 fs/namei.c:4372
__do_sys_mknod fs/namei.c:4405 [inline]
__se_sys_mknod fs/namei.c:4403 [inline]
__x64_sys_mknod+0x8c/0xa0 fs/namei.c:4403
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7346b8eec9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7347987038 EFLAGS: 00000246 ORIG_RAX: 0000000000000085
RAX: ffffffffffffffda RBX: 00007f7346de5fa0 RCX: 00007f7346b8eec9
RDX: 0000000000000700 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007f7346c11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7346de6038 R14: 00007f7346de5fa0 R15: 00007fff09db6038
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386
Code: 34 1a 49 81 c6 50 01 00 00 45 0f b7 3f 49 83 c5 02 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 eb 03 00 00 44 89 f8 31 d2 <66> 41 f7 75 00 0f b7 d8 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0
RSP: 0018:ffffc9000fd362a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000100000
RDX: 0000000000000000 RSI: 00000000000010fe RDI: 00000000000010ff
RBP: ffffc9000fd363a8 R08: 00313050554f5247 R09: 00313050554f5247
R10: dffffc0000000000 R11: ffffed100a449001 R12: dffffc0000000000
R13: ffff8880334dc2c2 R14: ffff888052248150 R15: 0000000000000000
FS: 00007f73479876c0(0000) GS:ffff88808d301000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000000 CR3: 000000004280a000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
0: 34 1a xor $0x1a,%al
2: 49 81 c6 50 01 00 00 add $0x150,%r14
9: 45 0f b7 3f movzwl (%r15),%r15d
d: 49 83 c5 02 add $0x2,%r13
11: 4c 89 e8 mov %r13,%rax
14: 48 c1 e8 03 shr $0x3,%rax
18: 42 0f b6 04 20 movzbl (%rax,%r12,1),%eax
1d: 84 c0 test %al,%al
1f: 0f 85 eb 03 00 00 jne 0x410
25: 44 89 f8 mov %r15d,%eax
28: 31 d2 xor %edx,%edx
* 2a: 66 41 f7 75 00 divw 0x0(%r13) <-- trapping instruction
2f: 0f b7 d8 movzwl %ax,%ebx
32: 4c 89 f0 mov %r14,%rax
35: 48 c1 e8 03 shr $0x3,%rax
39: 42 0f b6 04 20 movzbl (%rax,%r12,1),%eax
3e: 84 c0 test %al,%al


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 566771afc7a8 Merge tag 'v6.18-rc2-smb-server-fixes' of git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=112ec7e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=25811b07889c90db

dashboard link: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141ca614580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=156b4be2580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-566771af.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d8d15ef51fac/vmlinux-566771af.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7f77bbb0b916/bzImage-566771af.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/34711c27aae5/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1061bb04580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com

option from the mount to silence this warning.
=======================================================

ocfs2: Mounting device (7,0) on (node local, slot 0) with writeback data mode.

Oops: divide error: 0000 [#1] SMP KASAN NOPTI

CPU: 0 UID: 0 PID: 5467 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386
Code: 34 1a 49 81 c6 50 01 00 00 45 0f b7 3f 49 83 c5 02 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 eb 03 00 00 44 89 f8 31 d2 <66> 41 f7 75 00 0f b7 d8 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0

RSP: 0018:ffffc90002b2f080 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888000dba480
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90002b2f188 R08: 00313050554f5247 R09: 00313050554f5247
R10: dffffc0000000000 R11: ffffed1009f9b801 R12: dffffc0000000000
R13: ffff88804fcc24c2 R14: ffff88804fcdc150 R15: 0000000000000000
FS: 000055558f3fe500(0000) GS:ffff88808d733000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000001b2fd63fff CR3: 00000000431d7000 CR4: 0000000000352ef0

Call Trace:
<TASK>
ocfs2_block_group_alloc_discontig fs/ocfs2/suballoc.c:634 [inline]
ocfs2_block_group_alloc fs/ocfs2/suballoc.c:703 [inline]
ocfs2_reserve_suballoc_bits+0x20a6/0x4640 fs/ocfs2/suballoc.c:834

ocfs2_reserve_new_inode+0x4f4/0xcc0 fs/ocfs2/suballoc.c:1074
ocfs2_mknod+0x83c/0x2050 fs/ocfs2/namei.c:306
ocfs2_mkdir+0x191/0x440 fs/ocfs2/namei.c:659
vfs_mkdir+0x306/0x510 fs/namei.c:4453
do_mkdirat+0x247/0x590 fs/namei.c:4486
__do_sys_mkdirat fs/namei.c:4503 [inline]
__se_sys_mkdirat fs/namei.c:4501 [inline]
__x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4501

do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7f3f05d8efc9

Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007ffdff269308 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007f3f05fe5fa0 RCX: 00007f3f05d8efc9
RDX: 0000000000000000 RSI: 00002000000000c0 RDI: ffffffffffffff9c
RBP: 00007f3f05e11f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007f3f05fe5fa0 R14: 00007f3f05fe5fa0 R15: 0000000000000003

</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386
Code: 34 1a 49 81 c6 50 01 00 00 45 0f b7 3f 49 83 c5 02 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 eb 03 00 00 44 89 f8 31 d2 <66> 41 f7 75 00 0f b7 d8 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0

RSP: 0018:ffffc90002b2f080 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888000dba480
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90002b2f188 R08: 00313050554f5247 R09: 00313050554f5247
R10: dffffc0000000000 R11: ffffed1009f9b801 R12: dffffc0000000000
R13: ffff88804fcc24c2 R14: ffff88804fcdc150 R15: 0000000000000000
FS: 000055558f3fe500(0000) GS:ffff88808d733000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000001b2fd63fff CR3: 00000000431d7000 CR4: 0000000000352ef0

----------------
Code disassembly (best guess):
0: 34 1a xor $0x1a,%al
2: 49 81 c6 50 01 00 00 add $0x150,%r14
9: 45 0f b7 3f movzwl (%r15),%r15d
d: 49 83 c5 02 add $0x2,%r13
11: 4c 89 e8 mov %r13,%rax
14: 48 c1 e8 03 shr $0x3,%rax
18: 42 0f b6 04 20 movzbl (%rax,%r12,1),%eax
1d: 84 c0 test %al,%al
1f: 0f 85 eb 03 00 00 jne 0x410
25: 44 89 f8 mov %r15d,%eax
28: 31 d2 xor %edx,%edx
* 2a: 66 41 f7 75 00 divw 0x0(%r13) <-- trapping instruction
2f: 0f b7 d8 movzwl %ax,%ebx
32: 4c 89 f0 mov %r14,%rax
35: 48 c1 e8 03 shr $0x3,%rax
39: 42 0f b6 04 20 movzbl (%rax,%r12,1),%eax
3e: 84 c0 test %al,%al


---

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate cl_bpc in ocfs2_block_group_alloc to prevent divide-by-zero
Author: karti...@gmail.com

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

The chain allocator field cl_bpc (blocks per cluster) is read from disk
and used in division operations without validation. A corrupted filesystem
image with cl_bpc=0 causes a divide-by-zero crash in the kernel:

divide error: 0000 [#1] PREEMPT SMP KASAN

RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386

Call Trace:
ocfs2_block_group_alloc+0x7e9/0x1330 fs/ocfs2/suballoc.c:703

ocfs2_reserve_suballoc_bits+0x20a6/0x4640 fs/ocfs2/suballoc.c:834
ocfs2_reserve_new_inode+0x4f4/0xcc0 fs/ocfs2/suballoc.c:1074
ocfs2_mknod+0x83c/0x2050 fs/ocfs2/namei.c:306

This patch adds validation in ocfs2_block_group_alloc() to ensure cl_bpc
matches the expected value calculated from the superblock's cluster size
and block size. This validation follows the same pattern used elsewhere
in OCFS2 to verify on-disk structures against known-good values derived
from the superblock parameters.

The check is performed early in the allocation path, before any resources
are allocated or transactions started, ensuring clean error propagation.
If validation fails, the filesystem is marked read-only and the operation
returns -EUCLEAN (Structure needs cleaning), prompting the administrator
to run fsck.ocfs2.

The validation catches both:
- Zero values that cause divide-by-zero crashes
- Non-zero but incorrect values indicating filesystem corruption or
mismatched filesystem geometry

With this fix, mounting a corrupted filesystem produces:
OCFS2: ERROR (device loop0): ocfs2_block_group_alloc: Chain allocator
74 has corrupted cl_bpc: ondisk=0 expected=16
OCFS2: File system is now read-only.

Instead of a kernel crash.

Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
Tested-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ocfs2/suballoc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
index 6ac4dcd54588..9f3db59890c3 100644
--- a/fs/ocfs2/suballoc.c
+++ b/fs/ocfs2/suballoc.c
@@ -667,10 +667,22 @@ static int ocfs2_block_group_alloc(struct ocfs2_super *osb,
u16 alloc_rec;
struct buffer_head *bg_bh = NULL;
struct ocfs2_group_desc *bg;
+ u16 cl_bpc, expected_bpc;

BUG_ON(ocfs2_is_cluster_bitmap(alloc_inode));

cl = &fe->id2.i_chain;
+ cl_bpc = le16_to_cpu(cl->cl_bpc);
+ expected_bpc = 1 << (osb->s_clustersize_bits - alloc_inode->i_sb->s_blocksize_bits);
+ if (cl_bpc != expected_bpc) {
+ ocfs2_error(alloc_inode->i_sb,
+ "Chain allocator %llu has corrupted cl_bpc: ondisk=%u expected=%u\n",
+ (unsigned long long)le64_to_cpu(fe->i_blkno),
+ cl_bpc, expected_bpc);
+ status = -EUCLEAN;
+ goto bail;
+ }
+
status = ocfs2_reserve_clusters_with_limit(osb,
le16_to_cpu(cl->cl_cpg),
max_block, flags, &ac);
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Tested-by: syzbot+fd8af9...@syzkaller.appspotmail.com

Tested on:

commit: 72761a7e Merge tag 'driver-core-6.18-rc3' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13fa5614580000

kernel config: https://syzkaller.appspot.com/x/.config?x=25811b07889c90db
dashboard link: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=17d82c92580000

Note: testing is done by a robot and is best-effort only.

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH v2] ocfs2: validate cl_bpc in allocator inodes to prevent divide-by-zero

Author: karti...@gmail.com

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

The chain allocator field cl_bpc (blocks per cluster) is read from disk
and used in division operations without validation. A corrupted filesystem
image with cl_bpc=0 causes a divide-by-zero crash in the kernel:

divide error: 0000 [#1] PREEMPT SMP KASAN

RIP: 0010:ocfs2_bg_discontig_add_extent fs/ocfs2/suballoc.c:335 [inline]
RIP: 0010:ocfs2_block_group_fill+0x5bd/0xa70 fs/ocfs2/suballoc.c:386

Call Trace:
ocfs2_block_group_alloc+0x7e9/0x1330 fs/ocfs2/suballoc.c:703
ocfs2_reserve_suballoc_bits+0x20a6/0x4640 fs/ocfs2/suballoc.c:834
ocfs2_reserve_new_inode+0x4f4/0xcc0 fs/ocfs2/suballoc.c:1074
ocfs2_mknod+0x83c/0x2050 fs/ocfs2/namei.c:306

This patch adds validation in ocfs2_validate_inode_block() to ensure cl_bpc

matches the expected value calculated from the superblock's cluster size

and block size for chain allocator inodes (identified by OCFS2_CHAIN_FL).

Moving the validation to inode validation time (rather than allocation time)
has several benefits:
- Validates once when the inode is read, rather than on every allocation
- Protects all code paths that use cl_bpc (allocation, resize, etc.)
- Follows the existing pattern of inode validation in OCFS2
- Centralizes validation logic

The validation catches both:
- Zero values that cause divide-by-zero crashes
- Non-zero but incorrect values indicating filesystem corruption or
mismatched filesystem geometry

With this fix, mounting a corrupted filesystem produces:

OCFS2: ERROR (device loop0): ocfs2_validate_inode_block: Inode 74

has corrupted cl_bpc: ondisk=0 expected=16

Instead of a kernel crash.

Link: https://lore.kernel.org/ocfs2-devel/20251026132625.12...@gmail.com/T/#u [v1]

Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
Tested-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

Changes in v2:
- Moved validation from ocfs2_block_group_alloc() to ocfs2_validate_inode_block()
as suggested by Joseph Qi to benefit all code paths
- Added OCFS2_CHAIN_FL check to only validate chain allocator inodes
- Updated commit message to reflect the new location
---
fs/ocfs2/inode.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index fcc89856ab95..1b30bf336961 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -1502,7 +1502,22 @@ int ocfs2_validate_inode_block(struct super_block *sb,
le16_to_cpu(di->i_suballoc_slot));
goto bail;
}
-
+ /* Validate cl_bpc for chain allocator inodes */
+ if (le32_to_cpu(di->i_flags) & OCFS2_CHAIN_FL) {
+ struct ocfs2_super *osb = OCFS2_SB(sb);
+ struct ocfs2_chain_list *cl = &di->id2.i_chain;
+ u16 cl_bpc = le16_to_cpu(cl->cl_bpc);
+ u16 expected_bpc = 1 << (osb->s_clustersize_bits -
+ sb->s_blocksize_bits);
+

+ if (cl_bpc != expected_bpc) {

+ rc = ocfs2_error(sb,
+ "Inode %llu has corrupted cl_bpc: ondisk=%u expected=%u\n",
+ (unsigned long long)bh->b_blocknr,
+ cl_bpc, expected_bpc);

+ goto bail;
+ }
+ }

rc = 0;

bail:
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fd8af9...@syzkaller.appspotmail.com
Tested-by: syzbot+fd8af9...@syzkaller.appspotmail.com

Tested on:

commit: dcb6fa37 Linux 6.18-rc3
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1316d614580000
kernel config: https://syzkaller.appspot.com/x/.config?x=929790bc044e87d7

dashboard link: https://syzkaller.appspot.com/bug?extid=fd8af97c7227fe605d95
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=15e8a7e2580000