* [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
@ 2024-10-31 4:54 syzbot
2024-11-05 4:00 ` Andrew Morton
2024-12-11 15:59 ` syzbot
0 siblings, 2 replies; 7+ messages in thread
From: syzbot @ 2024-10-31 4:54 UTC (permalink / raw)
To: akpm, linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 850925a8133c Merge tag '9p-for-6.12-rc5' of https://github..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1346c940580000
kernel config: https://syzkaller.appspot.com/x/.config?x=309bb816d40abc28
dashboard link: https://syzkaller.appspot.com/bug?extid=ccc0e1cfdb72b664f0d8
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158ab65f980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120e6a87980000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/da8019730dec/disk-850925a8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b1ee80babbbc/vmlinux-850925a8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/462580e2ad54/bzImage-850925a8.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 1a 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:00007ffede422258 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 00007ffede422280 RCX: 00007f69e1b3c569
RDX: 0000000002000005 RSI: 0000000000003000 RDI: 000000002001a000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000080000000
R10: 0000000000011012 R11: 0000000000000246 R12: 00007ffede42227c
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
</TASK>
------------[ cut here ]------------
kernel BUG at mm/page_table_check.c:157!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 5850 Comm: syz-executor279 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:__page_table_check_zero+0x274/0x350 mm/page_table_check.c:157
Code: c1 0f 8c 39 fe ff ff 48 89 df e8 87 28 f3 ff e9 2c fe ff ff e8 dd 6a 89 ff 90 0f 0b e8 d5 6a 89 ff 90 0f 0b e8 cd 6a 89 ff 90 <0f> 0b f3 0f 1e fa 4c 89 f6 48 81 e6 ff 0f 00 00 31 ff e8 95 6f 89
RSP: 0018:ffffc900046bf6d8 EFLAGS: 00010293
RAX: ffffffff820b7fa3 RBX: dffffc0000000000 RCX: ffff88802fc13c00
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88801e97380c
RBP: ffff88801e97380c R08: ffff88801e97380f R09: 1ffff11003d2e701
R10: dffffc0000000000 R11: ffffed1003d2e702 R12: ffff88801e9737c0
R13: 1ffffffff34887b4 R14: 0000000000000002 R15: 0000000000000000
FS: 0000555570714380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f69e1b92385 CR3: 0000000073ae6000 CR4: 0000000000350ef0
Call Trace:
<TASK>
page_table_check_free include/linux/page_table_check.h:41 [inline]
free_pages_prepare mm/page_alloc.c:1109 [inline]
free_unref_page+0xd0f/0xf20 mm/page_alloc.c:2638
dec_usb_memory_use_count+0x259/0x350 drivers/usb/core/devio.c:198
mmap_region+0x2180/0x2a30 mm/mmap.c:1574
do_mmap+0x8f0/0x1000 mm/mmap.c:496
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588
ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f69e1b3c569
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 1a 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:00007ffede422258 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 00007ffede422280 RCX: 00007f69e1b3c569
RDX: 0000000002000005 RSI: 0000000000003000 RDI: 000000002001a000
RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000080000000
R10: 0000000000011012 R11: 0000000000000246 R12: 00007ffede42227c
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__page_table_check_zero+0x274/0x350 mm/page_table_check.c:157
Code: c1 0f 8c 39 fe ff ff 48 89 df e8 87 28 f3 ff e9 2c fe ff ff e8 dd 6a 89 ff 90 0f 0b e8 d5 6a 89 ff 90 0f 0b e8 cd 6a 89 ff 90 <0f> 0b f3 0f 1e fa 4c 89 f6 48 81 e6 ff 0f 00 00 31 ff e8 95 6f 89
RSP: 0018:ffffc900046bf6d8 EFLAGS: 00010293
RAX: ffffffff820b7fa3 RBX: dffffc0000000000 RCX: ffff88802fc13c00
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88801e97380c
RBP: ffff88801e97380c R08: ffff88801e97380f R09: 1ffff11003d2e701
R10: dffffc0000000000 R11: ffffed1003d2e702 R12: ffff88801e9737c0
R13: 1ffffffff34887b4 R14: 0000000000000002 R15: 0000000000000000
FS: 0000555570714380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f69e1b92385 CR3: 0000000073ae6000 CR4: 0000000000350ef0
----------------
Code disassembly (best guess):
0: 28 00 sub %al,(%rax)
2: 00 00 add %al,(%rax)
4: 75 05 jne 0xb
6: 48 83 c4 28 add $0x28,%rsp
a: c3 ret
b: e8 a1 1a 00 00 call 0x1ab1
10: 90 nop
11: 48 89 f8 mov %rdi,%rax
14: 48 89 f7 mov %rsi,%rdi
17: 48 89 d6 mov %rdx,%rsi
1a: 48 89 ca mov %rcx,%rdx
1d: 4d 89 c2 mov %r8,%r10
20: 4d 89 c8 mov %r9,%r8
23: 4c 8b 4c 24 08 mov 0x8(%rsp),%r9
28: 0f 05 syscall
* 2a: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction
30: 73 01 jae 0x33
32: c3 ret
33: 48 c7 c1 b8 ff ff ff mov $0xffffffffffffffb8,%rcx
3a: f7 d8 neg %eax
3c: 64 89 01 mov %eax,%fs:(%rcx)
3f: 48 rex.W
---
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 syzkaller@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 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-10-31 4:54 [syzbot] [mm?] kernel BUG in __page_table_check_zero (2) syzbot
@ 2024-11-05 4:00 ` Andrew Morton
2024-11-05 16:39 ` Alan Stern
2024-12-11 15:59 ` syzbot
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2024-11-05 4:00 UTC (permalink / raw)
To: syzbot; +Cc: linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs, linux-usb
On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following issue on:
Thanks. I'm suspecting some USB issue - fault injection was used to
trigger a memory allocation failure and dec_usb_memory_use_count() ended
up freeing an in-use page. Could USB folks please have a look?
> HEAD commit: 850925a8133c Merge tag '9p-for-6.12-rc5' of https://github..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=1346c940580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=309bb816d40abc28
> dashboard link: https://syzkaller.appspot.com/bug?extid=ccc0e1cfdb72b664f0d8
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158ab65f980000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120e6a87980000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/da8019730dec/disk-850925a8.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b1ee80babbbc/vmlinux-850925a8.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/462580e2ad54/bzImage-850925a8.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com
>
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 1a 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:00007ffede422258 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
> RAX: ffffffffffffffda RBX: 00007ffede422280 RCX: 00007f69e1b3c569
> RDX: 0000000002000005 RSI: 0000000000003000 RDI: 000000002001a000
> RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000080000000
> R10: 0000000000011012 R11: 0000000000000246 R12: 00007ffede42227c
> R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
> </TASK>
> ------------[ cut here ]------------
> kernel BUG at mm/page_table_check.c:157!
> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
> CPU: 1 UID: 0 PID: 5850 Comm: syz-executor279 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> RIP: 0010:__page_table_check_zero+0x274/0x350 mm/page_table_check.c:157
> Code: c1 0f 8c 39 fe ff ff 48 89 df e8 87 28 f3 ff e9 2c fe ff ff e8 dd 6a 89 ff 90 0f 0b e8 d5 6a 89 ff 90 0f 0b e8 cd 6a 89 ff 90 <0f> 0b f3 0f 1e fa 4c 89 f6 48 81 e6 ff 0f 00 00 31 ff e8 95 6f 89
> RSP: 0018:ffffc900046bf6d8 EFLAGS: 00010293
> RAX: ffffffff820b7fa3 RBX: dffffc0000000000 RCX: ffff88802fc13c00
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88801e97380c
> RBP: ffff88801e97380c R08: ffff88801e97380f R09: 1ffff11003d2e701
> R10: dffffc0000000000 R11: ffffed1003d2e702 R12: ffff88801e9737c0
> R13: 1ffffffff34887b4 R14: 0000000000000002 R15: 0000000000000000
> FS: 0000555570714380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f69e1b92385 CR3: 0000000073ae6000 CR4: 0000000000350ef0
> Call Trace:
> <TASK>
> page_table_check_free include/linux/page_table_check.h:41 [inline]
> free_pages_prepare mm/page_alloc.c:1109 [inline]
> free_unref_page+0xd0f/0xf20 mm/page_alloc.c:2638
> dec_usb_memory_use_count+0x259/0x350 drivers/usb/core/devio.c:198
> mmap_region+0x2180/0x2a30 mm/mmap.c:1574
> do_mmap+0x8f0/0x1000 mm/mmap.c:496
> vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588
> ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f69e1b3c569
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 1a 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:00007ffede422258 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
> RAX: ffffffffffffffda RBX: 00007ffede422280 RCX: 00007f69e1b3c569
> RDX: 0000000002000005 RSI: 0000000000003000 RDI: 000000002001a000
> RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000080000000
> R10: 0000000000011012 R11: 0000000000000246 R12: 00007ffede42227c
> R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__page_table_check_zero+0x274/0x350 mm/page_table_check.c:157
> Code: c1 0f 8c 39 fe ff ff 48 89 df e8 87 28 f3 ff e9 2c fe ff ff e8 dd 6a 89 ff 90 0f 0b e8 d5 6a 89 ff 90 0f 0b e8 cd 6a 89 ff 90 <0f> 0b f3 0f 1e fa 4c 89 f6 48 81 e6 ff 0f 00 00 31 ff e8 95 6f 89
> RSP: 0018:ffffc900046bf6d8 EFLAGS: 00010293
> RAX: ffffffff820b7fa3 RBX: dffffc0000000000 RCX: ffff88802fc13c00
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88801e97380c
> RBP: ffff88801e97380c R08: ffff88801e97380f R09: 1ffff11003d2e701
> R10: dffffc0000000000 R11: ffffed1003d2e702 R12: ffff88801e9737c0
> R13: 1ffffffff34887b4 R14: 0000000000000002 R15: 0000000000000000
> FS: 0000555570714380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f69e1b92385 CR3: 0000000073ae6000 CR4: 0000000000350ef0
> ----------------
> Code disassembly (best guess):
> 0: 28 00 sub %al,(%rax)
> 2: 00 00 add %al,(%rax)
> 4: 75 05 jne 0xb
> 6: 48 83 c4 28 add $0x28,%rsp
> a: c3 ret
> b: e8 a1 1a 00 00 call 0x1ab1
> 10: 90 nop
> 11: 48 89 f8 mov %rdi,%rax
> 14: 48 89 f7 mov %rsi,%rdi
> 17: 48 89 d6 mov %rdx,%rsi
> 1a: 48 89 ca mov %rcx,%rdx
> 1d: 4d 89 c2 mov %r8,%r10
> 20: 4d 89 c8 mov %r9,%r8
> 23: 4c 8b 4c 24 08 mov 0x8(%rsp),%r9
> 28: 0f 05 syscall
> * 2a: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction
> 30: 73 01 jae 0x33
> 32: c3 ret
> 33: 48 c7 c1 b8 ff ff ff mov $0xffffffffffffffb8,%rcx
> 3a: f7 d8 neg %eax
> 3c: 64 89 01 mov %eax,%fs:(%rcx)
> 3f: 48 rex.W
>
>
> ---
> 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 syzkaller@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 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-11-05 4:00 ` Andrew Morton
@ 2024-11-05 16:39 ` Alan Stern
2024-11-05 19:02 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Alan Stern @ 2024-11-05 16:39 UTC (permalink / raw)
To: Andrew Morton
Cc: syzbot, linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs,
linux-usb
On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:
> On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
>
> Thanks. I'm suspecting some USB issue - fault injection was used to
> trigger a memory allocation failure and dec_usb_memory_use_count() ended
> up freeing an in-use page. Could USB folks please have a look?
Andrew, I'm not sure what to look for. Can you read through
usbdev_mmap() in drivers/usb/core/devio.c, along with the four short
routines preceding it, and let us know if anything seems obviously
wrong?
Alan Stern
> > HEAD commit: 850925a8133c Merge tag '9p-for-6.12-rc5' of https://github..
> > git tree: upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=1346c940580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=309bb816d40abc28
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ccc0e1cfdb72b664f0d8
> > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158ab65f980000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120e6a87980000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/da8019730dec/disk-850925a8.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/b1ee80babbbc/vmlinux-850925a8.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/462580e2ad54/bzImage-850925a8.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com
> >
> > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 1a 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:00007ffede422258 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
> > RAX: ffffffffffffffda RBX: 00007ffede422280 RCX: 00007f69e1b3c569
> > RDX: 0000000002000005 RSI: 0000000000003000 RDI: 000000002001a000
> > RBP: 0000000000000001 R08: 0000000000000003 R09: 0000000080000000
> > R10: 0000000000011012 R11: 0000000000000246 R12: 00007ffede42227c
> > R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
> > </TASK>
> > ------------[ cut here ]------------
> > kernel BUG at mm/page_table_check.c:157!
> > Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > CPU: 1 UID: 0 PID: 5850 Comm: syz-executor279 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> > RIP: 0010:__page_table_check_zero+0x274/0x350 mm/page_table_check.c:157
> > Code: c1 0f 8c 39 fe ff ff 48 89 df e8 87 28 f3 ff e9 2c fe ff ff e8 dd 6a 89 ff 90 0f 0b e8 d5 6a 89 ff 90 0f 0b e8 cd 6a 89 ff 90 <0f> 0b f3 0f 1e fa 4c 89 f6 48 81 e6 ff 0f 00 00 31 ff e8 95 6f 89
> > RSP: 0018:ffffc900046bf6d8 EFLAGS: 00010293
> > RAX: ffffffff820b7fa3 RBX: dffffc0000000000 RCX: ffff88802fc13c00
> > RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88801e97380c
> > RBP: ffff88801e97380c R08: ffff88801e97380f R09: 1ffff11003d2e701
> > R10: dffffc0000000000 R11: ffffed1003d2e702 R12: ffff88801e9737c0
> > R13: 1ffffffff34887b4 R14: 0000000000000002 R15: 0000000000000000
> > FS: 0000555570714380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f69e1b92385 CR3: 0000000073ae6000 CR4: 0000000000350ef0
> > Call Trace:
> > <TASK>
> > page_table_check_free include/linux/page_table_check.h:41 [inline]
> > free_pages_prepare mm/page_alloc.c:1109 [inline]
> > free_unref_page+0xd0f/0xf20 mm/page_alloc.c:2638
> > dec_usb_memory_use_count+0x259/0x350 drivers/usb/core/devio.c:198
> > mmap_region+0x2180/0x2a30 mm/mmap.c:1574
> > do_mmap+0x8f0/0x1000 mm/mmap.c:496
> > vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588
> > ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-11-05 16:39 ` Alan Stern
@ 2024-11-05 19:02 ` Andrew Morton
2024-11-05 20:42 ` Alan Stern
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2024-11-05 19:02 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs,
linux-usb
On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:
> > On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com> wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> >
> > Thanks. I'm suspecting some USB issue - fault injection was used to
> > trigger a memory allocation failure and dec_usb_memory_use_count() ended
> > up freeing an in-use page. Could USB folks please have a look?
>
> Andrew, I'm not sure what to look for.
Thanks for looking.
> Can you read through
> usbdev_mmap() in drivers/usb/core/devio.c, along with the four short
> routines preceding it, and let us know if anything seems obviously
> wrong?
All I see is lots of USB code which I don't understand ;) It seems odd
that usbdev_mmap() calls dec_usb_memory_use_count() on some error
paths, but goes direct to usbfs_decrease_memory_usage() on others.
Did you try running the "C reproducer"?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-11-05 19:02 ` Andrew Morton
@ 2024-11-05 20:42 ` Alan Stern
2024-11-05 21:30 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Alan Stern @ 2024-11-05 20:42 UTC (permalink / raw)
To: Andrew Morton
Cc: syzbot, linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs,
linux-usb
On Tue, Nov 05, 2024 at 11:02:36AM -0800, Andrew Morton wrote:
> On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:
> > > On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > >
> > > Thanks. I'm suspecting some USB issue - fault injection was used to
> > > trigger a memory allocation failure and dec_usb_memory_use_count() ended
> > > up freeing an in-use page. Could USB folks please have a look?
> >
> > Andrew, I'm not sure what to look for.
>
> Thanks for looking.
>
> > Can you read through
> > usbdev_mmap() in drivers/usb/core/devio.c, along with the four short
> > routines preceding it, and let us know if anything seems obviously
> > wrong?
>
> All I see is lots of USB code which I don't understand ;) It seems odd
Well, I wouldn't expect you to understand the USB-specific stuff. I was
really asking about the memory-management calls and error handling.
> that usbdev_mmap() calls dec_usb_memory_use_count() on some error
> paths, but goes direct to usbfs_decrease_memory_usage() on others.
The paths that call dec_usb_memory_use_count() are those on which a
memory buffer has been allocated and needs to be deallocated. That
routine then calls usbfs_decrease_memory_usage() as needed.
> Did you try running the "C reproducer"?
No, I haven't. I haven't had much time to work on this. In fact, I
couldn't even tell exactly which call in dec_usb_memory_use_count()
caused the fault; the line number listed in the bug report didn't match
up with any obvious suspects in my copy of the kernel source. Was it
the kfree(usbm) call?
Alan Stern
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-11-05 20:42 ` Alan Stern
@ 2024-11-05 21:30 ` Andrew Morton
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2024-11-05 21:30 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, linux-kernel, linux-mm, pasha.tatashin, syzkaller-bugs,
linux-usb
On Tue, 5 Nov 2024 15:42:12 -0500 Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, Nov 05, 2024 at 11:02:36AM -0800, Andrew Morton wrote:
> > On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:
> > > > On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@syzkaller.appspotmail.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > >
> > > > Thanks. I'm suspecting some USB issue - fault injection was used to
> > > > trigger a memory allocation failure and dec_usb_memory_use_count() ended
> > > > up freeing an in-use page. Could USB folks please have a look?
> > >
> > > Andrew, I'm not sure what to look for.
> >
> > Thanks for looking.
> >
> > > Can you read through
> > > usbdev_mmap() in drivers/usb/core/devio.c, along with the four short
> > > routines preceding it, and let us know if anything seems obviously
> > > wrong?
> >
> > All I see is lots of USB code which I don't understand ;) It seems odd
>
> Well, I wouldn't expect you to understand the USB-specific stuff. I was
> really asking about the memory-management calls and error handling.
>
> > that usbdev_mmap() calls dec_usb_memory_use_count() on some error
> > paths, but goes direct to usbfs_decrease_memory_usage() on others.
>
> The paths that call dec_usb_memory_use_count() are those on which a
> memory buffer has been allocated and needs to be deallocated. That
> routine then calls usbfs_decrease_memory_usage() as needed.
>
> > Did you try running the "C reproducer"?
>
> No, I haven't. I haven't had much time to work on this. In fact, I
> couldn't even tell exactly which call in dec_usb_memory_use_count()
> caused the fault; the line number listed in the bug report didn't match
> up with any obvious suspects in my copy of the kernel source. Was it
> the kfree(usbm) call?
Check out the sysbot commit first: 850925a8133c. Line 198 is the
hcd_buffer_free_pages() call.
hcd_buffer_free_pages() doesn't appear in the backtrace - a bunch of
things I'd expect to be present aren't there.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)
2024-10-31 4:54 [syzbot] [mm?] kernel BUG in __page_table_check_zero (2) syzbot
2024-11-05 4:00 ` Andrew Morton
@ 2024-12-11 15:59 ` syzbot
1 sibling, 0 replies; 7+ messages in thread
From: syzbot @ 2024-12-11 15:59 UTC (permalink / raw)
To: akpm, broonie, hdanton, liam.howlett, linux-kernel, linux-mm,
linux-usb, lorenzo.stoakes, pasha.tatashin, stern,
syzkaller-bugs, vbabka
syzbot suspects this issue was fixed by commit:
commit 5de195060b2e251a835f622759550e6202167641
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Tue Oct 29 18:11:48 2024 +0000
mm: resolve faulty mmap_region() error path behaviour
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1507b8f8580000
start commit: 850925a8133c Merge tag '9p-for-6.12-rc5' of https://github..
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=309bb816d40abc28
dashboard link: https://syzkaller.appspot.com/bug?extid=ccc0e1cfdb72b664f0d8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158ab65f980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120e6a87980000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: mm: resolve faulty mmap_region() error path behaviour
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-12-11 15:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-31 4:54 [syzbot] [mm?] kernel BUG in __page_table_check_zero (2) syzbot
2024-11-05 4:00 ` Andrew Morton
2024-11-05 16:39 ` Alan Stern
2024-11-05 19:02 ` Andrew Morton
2024-11-05 20:42 ` Alan Stern
2024-11-05 21:30 ` Andrew Morton
2024-12-11 15:59 ` syzbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox