[syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    f9f24ca362a4 Add linux-next specific files for 20241031
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=12052630580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=328572ed4d152be9
dashboard link: https://syzkaller.appspot.com/bug?extid=05c0f12a4d43d656817e
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=15abc6f7980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10eb655f980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/eb84549dd6b3/disk-f9f24ca3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/beb29bdfa297/vmlinux-f9f24ca3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8881fe3245ad/bzImage-f9f24ca3.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 UID: 0 PID: 5845 Comm: syz-executor176 Not tainted 6.12.0-rc5-next-20241031-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:headpage_already_acct io_uring/rsrc.c:584 [inline]
RIP: 0010:io_buffer_account_pin io_uring/rsrc.c:614 [inline]
RIP: 0010:io_sqe_buffer_register+0xaa8/0x2cf0 io_uring/rsrc.c:758
Code: 00 fc ff df 80 3c 08 00 74 08 48 89 df e8 b0 8a 55 fd 48 8b 1b 48 83 c3 18 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 df e8 8a 8a 55 fd 48 8b 03 48 89 44 24 60
RSP: 0018:ffffc90003faf640 EFLAGS: 00010206
RAX: 0000000000000003 RBX: 0000000000000018 RCX: dffffc0000000000
RDX: ffff88807ef14128 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90003faf7f0 R08: ffffffff84a9ce37 R09: 1ffffd40003a8000
R10: dffffc0000000000 R11: fffff940003a8001 R12: ffffea0001d40000
R13: 0000000000000006 R14: 1ffff110060dc350 R15: ffff8880306e1a80
FS:  00005555684d7380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010404 CR3: 000000007ea62000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 __io_sqe_buffers_update io_uring/rsrc.c:257 [inline]
 __io_register_rsrc_update+0x5c8/0x1320 io_uring/rsrc.c:295
 io_register_rsrc_update+0x1d1/0x230 io_uring/rsrc.c:326
 __do_sys_io_uring_register io_uring/register.c:938 [inline]
 __se_sys_io_uring_register+0x8ee/0x40d0 io_uring/register.c:915
 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:0x7f96c01b8469
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc4e36b3a8 EFLAGS: 00000246 ORIG_RAX: 00000000000001ab
RAX: ffffffffffffffda RBX: 00000000000004b5 RCX: 00007f96c01b8469
RDX: 0000000020000600 RSI: 0000000000000010 RDI: 0000000000000003
RBP: 0000000000000003 R08: 00000000000ac5f8 R09: 00000000000ac5f8
R10: 0000000000000020 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffc4e36b578 R14: 0000000000000001 R15: 0000000000000001
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:headpage_already_acct io_uring/rsrc.c:584 [inline]
RIP: 0010:io_buffer_account_pin io_uring/rsrc.c:614 [inline]
RIP: 0010:io_sqe_buffer_register+0xaa8/0x2cf0 io_uring/rsrc.c:758
Code: 00 fc ff df 80 3c 08 00 74 08 48 89 df e8 b0 8a 55 fd 48 8b 1b 48 83 c3 18 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 df e8 8a 8a 55 fd 48 8b 03 48 89 44 24 60
RSP: 0018:ffffc90003faf640 EFLAGS: 00010206
RAX: 0000000000000003 RBX: 0000000000000018 RCX: dffffc0000000000
RDX: ffff88807ef14128 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90003faf7f0 R08: ffffffff84a9ce37 R09: 1ffffd40003a8000
R10: dffffc0000000000 R11: fffff940003a8001 R12: ffffea0001d40000
R13: 0000000000000006 R14: 1ffff110060dc350 R15: ffff8880306e1a80
FS:  00005555684d7380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f96c017d020 CR3: 000000007ea62000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 3 bytes skipped:
   0:	df 80 3c 08 00 74    	filds  0x7400083c(%rax)
   6:	08 48 89             	or     %cl,-0x77(%rax)
   9:	df e8                	fucomip %st(0),%st
   b:	b0 8a                	mov    $0x8a,%al
   d:	55                   	push   %rbp
   e:	fd                   	std
   f:	48 8b 1b             	mov    (%rbx),%rbx
  12:	48 83 c3 18          	add    $0x18,%rbx
  16:	48 89 d8             	mov    %rbx,%rax
  19:	48 c1 e8 03          	shr    $0x3,%rax
  1d:	48 b9 00 00 00 00 00 	movabs $0xdffffc0000000000,%rcx
  24:	fc ff df
* 27:	80 3c 08 00          	cmpb   $0x0,(%rax,%rcx,1) <-- trapping instruction
  2b:	74 08                	je     0x35
  2d:	48 89 df             	mov    %rbx,%rdi
  30:	e8 8a 8a 55 fd       	call   0xfd558abf
  35:	48 8b 03             	mov    (%rbx),%rax
  38:	48 89 44 24 60       	mov    %rax,0x60(%rsp)


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

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Jens Axboe]

On 11/1/24 2:07 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    f9f24ca362a4 Add linux-next specific files for 20241031
> git tree:       linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=12052630580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=328572ed4d152be9
> dashboard link: https://syzkaller.appspot.com/bug?extid=05c0f12a4d43d656817e
> 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=15abc6f7980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10eb655f980000

Same deal:

#syz test: git://git.kernel.dk/linux for-6.13/io_uring

-- 
Jens Axboe

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[syzbot]

Hello,

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

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

Tested on:

commit:         6b1c1819 io_uring/rsrc: fix headpage checking for spar..
git tree:       git://git.kernel.dk/linux for-6.13/io_uring
console output: https://syzkaller.appspot.com/x/log.txt?x=10ced340580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=37061a3807403bdc
dashboard link: https://syzkaller.appspot.com/bug?extid=05c0f12a4d43d656817e
compiler:       Debian clang version 15.0.6, 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.

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[syzbot]

syzbot has bisected this issue to:

commit 661768085e99aad356ebc77d78ac41fd02eccbe3
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Oct 30 15:51:58 2024 +0000

    io_uring/rsrc: get rid of the empty node and dummy_ubuf

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1586e987980000
start commit:   f9f24ca362a4 Add linux-next specific files for 20241031
git tree:       linux-next
final oops:     https://syzkaller.appspot.com/x/report.txt?x=1786e987980000
console output: https://syzkaller.appspot.com/x/log.txt?x=1386e987980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=328572ed4d152be9
dashboard link: https://syzkaller.appspot.com/bug?extid=05c0f12a4d43d656817e
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15abc6f7980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10eb655f980000

Reported-by: syzbot+05c0f12a4d43d656817e@syzkaller.appspotmail.com
Fixes: 661768085e99 ("io_uring/rsrc: get rid of the empty node and dummy_ubuf")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Jens Axboe]

#syz fix: io_uring/rsrc: get rid of the empty node and dummy_ubuf

-- 
Jens Axboe

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Aleksandr Nogikh]

Hi Jens,

Just in case:

Syzbot reported this commit as the result of the cause (bug origin)
bisection, not as the commit after which the problem was gone. So
(unless it actually is a fixing commit) reporting it back via #syz fix
is not correct.

-- 
Aleksandr

On Wed, Dec 4, 2024 at 6:07 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> #syz fix: io_uring/rsrc: get rid of the empty node and dummy_ubuf
>
> --
> Jens Axboe
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/1ce3a220-7f68-4a68-a76c-b37fdf9bfc70%40kernel.dk.

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Jens Axboe]

On 12/4/24 10:11 AM, Aleksandr Nogikh wrote:
> Hi Jens,
> 
> Just in case:
> 
> Syzbot reported this commit as the result of the cause (bug origin)
> bisection, not as the commit after which the problem was gone. So
> (unless it actually is a fixing commit) reporting it back via #syz fix
> is not correct.

The commit got fixed, and hence there isn't a good way to convey this
to syzbot as far as I can tell. Just marking the updated one as the
fixer seems to be the best/closest option.

Other option is to mark it as invalid, but that also doesn't seem right.

I'm fine doing whatever to get issues like this closed, but it's not
an uncommon thing to have a buggy commit that's not upstream yet be
fixed up and hence not have the issue anymore.

-- 
Jens Axboe

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Aleksandr Nogikh]

On Wed, Dec 4, 2024 at 6:14 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 12/4/24 10:11 AM, Aleksandr Nogikh wrote:
> > Hi Jens,
> >
> > Just in case:
> >
> > Syzbot reported this commit as the result of the cause (bug origin)
> > bisection, not as the commit after which the problem was gone. So
> > (unless it actually is a fixing commit) reporting it back via #syz fix
> > is not correct.
>
> The commit got fixed, and hence there isn't a good way to convey this
> to syzbot as far as I can tell. Just marking the updated one as the
> fixer seems to be the best/closest option.
>
> Other option is to mark it as invalid, but that also doesn't seem right.
>
> I'm fine doing whatever to get issues like this closed, but it's not
> an uncommon thing to have a buggy commit that's not upstream yet be
> fixed up and hence not have the issue anymore.

I see. You are right, thanks for the explanation!

There's indeed no better way to convey this at the moment. I've filed
https://github.com/google/syzkaller/issues/5567 to discuss what can be
done.

-- 
Aleksandr

>
> --
> Jens Axboe
>
> --

Re: [syzbot] [io-uring?] general protection fault in io_sqe_buffer_register

[Jens Axboe]

On 12/4/24 10:34 AM, Aleksandr Nogikh wrote:
> On Wed, Dec 4, 2024 at 6:14 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 12/4/24 10:11 AM, Aleksandr Nogikh wrote:
>>> Hi Jens,
>>>
>>> Just in case:
>>>
>>> Syzbot reported this commit as the result of the cause (bug origin)
>>> bisection, not as the commit after which the problem was gone. So
>>> (unless it actually is a fixing commit) reporting it back via #syz fix
>>> is not correct.
>>
>> The commit got fixed, and hence there isn't a good way to convey this
>> to syzbot as far as I can tell. Just marking the updated one as the
>> fixer seems to be the best/closest option.
>>
>> Other option is to mark it as invalid, but that also doesn't seem right.
>>
>> I'm fine doing whatever to get issues like this closed, but it's not
>> an uncommon thing to have a buggy commit that's not upstream yet be
>> fixed up and hence not have the issue anymore.
> 
> I see. You are right, thanks for the explanation!
> 
> There's indeed no better way to convey this at the moment. I've filed
> https://github.com/google/syzkaller/issues/5567 to discuss what can be
> done.

Thanks! Guess I wasn't totally blind, I did check to see if there was
a better way to do this currently and didn't spot it.

-- 
Jens Axboe