Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)

On Wed, 30 Oct 2024 21:54:22 -0700 syzbot [off-list ref] 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: <redacted>

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

86 more quoted lines

On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:

On Wed, 30 Oct 2024 21:54:22 -0700 syzbot [off-list ref] wrote:

quoted

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

quoted

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: <redacted>

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

14 more quoted lines

On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern [off-list ref] wrote:

On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:

quoted

On Wed, 30 Oct 2024 21:54:22 -0700 syzbot [off-list ref] wrote:

quoted

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"?

On Tue, Nov 05, 2024 at 11:02:36AM -0800, Andrew Morton wrote:

On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern [off-list ref] wrote:

quoted

On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:

quoted

On Wed, 30 Oct 2024 21:54:22 -0700 syzbot [off-list ref] wrote:

quoted

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.

quoted

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

On Tue, 5 Nov 2024 15:42:12 -0500 Alan Stern [off-list ref] wrote:

On Tue, Nov 05, 2024 at 11:02:36AM -0800, Andrew Morton wrote:

quoted

On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern [off-list ref] wrote:

quoted

On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote:

quoted

On Wed, 30 Oct 2024 21:54:22 -0700 syzbot [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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 

2 more quoted lines

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.