[syzbot] [jfs?] divide error in dbAllocAG

23 views
Skip to first unread message

syzbot

unread,
Dec 2, 2024, 11:02:24 PM12/2/24
to ax...@kernel.dk, jfs-dis...@lists.sourceforge.net, kris...@klausen.dk, linux...@vger.kernel.org, linux-...@vger.kernel.org, sha...@kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: 7af08b57bcb9 Merge tag 'trace-v6.13-2' of git://git.kernel..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=15e03f5f980000
kernel config: https://syzkaller.appspot.com/x/.config?x=29e5eaaea951b791
dashboard link: https://syzkaller.appspot.com/bug?extid=7c808908291a569281a9
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=162573c0580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=156dcd30580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/815d3cc889bc/disk-7af08b57.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/fa365742e0ed/vmlinux-7af08b57.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ea9d8aace8b7/bzImage-7af08b57.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/83512543e1fa/mount_0.gz

The issue was bisected to:

commit 2b9ac22b12a266eb4fec246a07b504dd4983b16b
Author: Kristian Klausen <kris...@klausen.dk>
Date: Fri Jun 18 11:51:57 2021 +0000

loop: Fix missing discard support when using LOOP_CONFIGURE

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17166d30580000
final oops: https://syzkaller.appspot.com/x/report.txt?x=14966d30580000
console output: https://syzkaller.appspot.com/x/log.txt?x=10966d30580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7c8089...@syzkaller.appspotmail.com
Fixes: 2b9ac22b12a2 ("loop: Fix missing discard support when using LOOP_CONFIGURE")

loop0: detected capacity change from 0 to 32768
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5857 Comm: syz-executor194 Not tainted 6.12.0-syzkaller-10689-g7af08b57bcb9 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:dbAllocAG+0x414/0xd30 fs/jfs/jfs_dmap.c:1399
Code: 03 0f b6 0c 11 48 89 fa 83 e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 a7 08 00 00 41 8b 4d 2c 49 8d 7d 30 99 48 89 fe 48 c1 ee 03 <f7> f9 48 ba 00 00 00 00 00 fc ff df 0f b6 14 16 84 d2 74 09 80 fa
RSP: 0018:ffffc9000450fbc8 EFLAGS: 00010216
RAX: 0000000000000400 RBX: 000000000000000a RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffff11004cce406 RDI: ffff888026672030
RBP: 0000000000000000 R08: 0000000000000005 R09: 000000000000001f
R10: 000000000000000a R11: 0000000000000002 R12: ffff88807650f000
R13: ffff888026672000 R14: 0000000000000000 R15: 000000000000000c
FS: 000055558401d380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000557f78216048 CR3: 00000000772e0000 CR4: 0000000000350ef0
Call Trace:
<TASK>
dbDiscardAG+0x249/0x7c0 fs/jfs/jfs_dmap.c:1613
jfs_ioc_trim+0x3fb/0x5c0 fs/jfs/jfs_discard.c:105
jfs_ioctl+0x335/0x430 fs/jfs/ioctl.c:131
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl fs/ioctl.c:892 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fc4a885b679
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 61 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc0fc54e38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffc0fc55008 RCX: 00007fc4a885b679
RDX: 0000000020000080 RSI: 00000000c0185879 RDI: 0000000000000004
RBP: 00007fc4a88d4610 R08: 0000000000000000 R09: 00007ffc0fc55008
R10: 0000000000005ea7 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffc0fc54ff8 R14: 0000000000000001 R15: 0000000000000001
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:dbAllocAG+0x414/0xd30 fs/jfs/jfs_dmap.c:1399
Code: 03 0f b6 0c 11 48 89 fa 83 e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 a7 08 00 00 41 8b 4d 2c 49 8d 7d 30 99 48 89 fe 48 c1 ee 03 <f7> f9 48 ba 00 00 00 00 00 fc ff df 0f b6 14 16 84 d2 74 09 80 fa
RSP: 0018:ffffc9000450fbc8 EFLAGS: 00010216
RAX: 0000000000000400 RBX: 000000000000000a RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffff11004cce406 RDI: ffff888026672030
RBP: 0000000000000000 R08: 0000000000000005 R09: 000000000000001f
R10: 000000000000000a R11: 0000000000000002 R12: ffff88807650f000
R13: ffff888026672000 R14: 0000000000000000 R15: 000000000000000c
FS: 000055558401d380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000557f78216048 CR3: 00000000772e0000 CR4: 0000000000350ef0
----------------
Code disassembly (best guess):
0: 03 0f add (%rdi),%ecx
2: b6 0c mov $0xc,%dh
4: 11 48 89 adc %ecx,-0x77(%rax)
7: fa cli
8: 83 e2 07 and $0x7,%edx
b: 83 c2 03 add $0x3,%edx
e: 38 ca cmp %cl,%dl
10: 7c 08 jl 0x1a
12: 84 c9 test %cl,%cl
14: 0f 85 a7 08 00 00 jne 0x8c1
1a: 41 8b 4d 2c mov 0x2c(%r13),%ecx
1e: 49 8d 7d 30 lea 0x30(%r13),%rdi
22: 99 cltd
23: 48 89 fe mov %rdi,%rsi
26: 48 c1 ee 03 shr $0x3,%rsi
* 2a: f7 f9 idiv %ecx <-- trapping instruction
2c: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
33: fc ff df
36: 0f b6 14 16 movzbl (%rsi,%rdx,1),%edx
3a: 84 d2 test %dl,%dl
3c: 74 09 je 0x47
3e: 80 .byte 0x80
3f: fa cli


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

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.

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

Edward Adam Davis

unread,
Dec 3, 2024, 2:56:53 AM12/3/24
to syzbot+7c8089...@syzkaller.appspotmail.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com

syzbot

unread,
Dec 3, 2024, 3:21:06 AM12/3/24
to ead...@qq.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

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

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

Tested on:

commit: 62cc82b7 jfs: check agwidth and agheight before alloca..
git tree: https://github.com/ea1davis/linux jfs/syz
console output: https://syzkaller.appspot.com/x/log.txt?x=11a7afc0580000
kernel config: https://syzkaller.appspot.com/x/.config?x=18d90fa8ec96d8b0
dashboard link: https://syzkaller.appspot.com/bug?extid=7c808908291a569281a9
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

Edward Adam Davis

unread,
Dec 3, 2024, 3:53:58 AM12/3/24
to syzbot+7c8089...@syzkaller.appspotmail.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
#syz test: https://github.com/ea1davis/linux jfs/syzv2

syzbot

unread,
Dec 3, 2024, 4:24:04 AM12/3/24
to ead...@qq.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

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

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

Tested on:

commit: a4326560 jfs: check agwidth and agheight when dbmount
git tree: https://github.com/ea1davis/linux jfs/syzv2
console output: https://syzkaller.appspot.com/x/log.txt?x=113740f8580000

Edward Adam Davis

unread,
Dec 3, 2024, 4:47:23 AM12/3/24
to syzbot+7c8089...@syzkaller.appspotmail.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
#syz test: https://github.com/ea1davis/linux jfs/syzv3

Edward Adam Davis

unread,
Dec 3, 2024, 5:22:37 AM12/3/24
to syzbot+7c8089...@syzkaller.appspotmail.com, ax...@kernel.dk, jfs-dis...@lists.sourceforge.net, kris...@klausen.dk, linux...@vger.kernel.org, linux-...@vger.kernel.org, sha...@kernel.org, syzkall...@googlegroups.com
The width in dmapctl of the AG is zero, it trigger a divide error when
calculating the control page level in dbAllocAG.

To avoid this issue, add a check for agwidth in dbAllocAG.

Reported-and-tested-by: syzbot+7c8089...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7c808908291a569281a9
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
fs/jfs/jfs_dmap.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index f9009e4f9ffd..2377102d9c4c 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -1373,6 +1373,11 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results)
return (rc);
}

+ if (!bmp->db_agwidth) {
+ jfs_error(bmp->db_ipbmap->i_sb, "width in dmapctl of the AG is zero\n");
+ return -EIO;
+ }
+
/* the buffer for the dmap control page that fully describes the
* allocation group.
*/
--
2.47.0

syzbot

unread,
Dec 3, 2024, 5:24:04 AM12/3/24
to ead...@qq.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

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

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

Tested on:

commit: 842f896c jfs: check agwidth before calculating the con..
git tree: https://github.com/ea1davis/linux jfs/syzv3
console output: https://syzkaller.appspot.com/x/log.txt?x=17ee75e8580000

Dave Kleikamp

unread,
Feb 19, 2025, 4:20:56 PM2/19/25
to Edward Adam Davis, syzbot+7c8089...@syzkaller.appspotmail.com, ax...@kernel.dk, jfs-dis...@lists.sourceforge.net, syzkall...@googlegroups.com, linux-...@vger.kernel.org, linux...@vger.kernel.org, kris...@klausen.dk
Catching up on long-ignored emails.

On 12/3/24 4:22AM, Edward Adam Davis via Jfs-discussion wrote:
> The width in dmapctl of the AG is zero, it trigger a divide error when
> calculating the control page level in dbAllocAG.
>
> To avoid this issue, add a check for agwidth in dbAllocAG.

This value shouldn't change unless the filesystem is resized. I would
prefer that the check was made once in dbMount().

Shaggy

Edward Adam Davis

unread,
Feb 20, 2025, 6:24:33 AM2/20/25
to dave.k...@oracle.com, ax...@kernel.dk, jfs-dis...@lists.sourceforge.net, kris...@klausen.dk, linux...@vger.kernel.org, linux-...@vger.kernel.org, sha...@kernel.org, syzkall...@googlegroups.com
The width in dmapctl of the AG is zero, it trigger a divide error when
calculating the control page level in dbAllocAG.

To avoid this issue, add a check for agwidth in dbAllocAG.

V1 -> V2: move the check to dbMount

fs/jfs/jfs_dmap.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index f9009e4f9ffd..62f55e7ed840 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -204,6 +204,10 @@ int dbMount(struct inode *ipbmap)
bmp->db_aglevel = le32_to_cpu(dbmp_le->dn_aglevel);
bmp->db_agheight = le32_to_cpu(dbmp_le->dn_agheight);
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
+ if (!bmp->db_agwidth) {
+ err = -EINVAL;
+ goto err_release_metapage;
+ }
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
if (bmp->db_agl2size > L2MAXL2SIZE - L2MAXAG ||
--
2.43.0

Dave Kleikamp

unread,
Feb 20, 2025, 11:21:27 AM2/20/25
to Edward Adam Davis, ax...@kernel.dk, jfs-dis...@lists.sourceforge.net, kris...@klausen.dk, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On 2/20/25 5:24AM, Edward Adam Davis wrote:
> The width in dmapctl of the AG is zero, it trigger a divide error when
> calculating the control page level in dbAllocAG.
>
> To avoid this issue, add a check for agwidth in dbAllocAG.

Looks good. Will add this to jfs-next.

Thanks,
Shaggy
Reply all
Reply to author
Forward
0 new messages