[syzbot] general protection fault in __io_arm_poll_handler

[syzbot] general protection fault in __io_arm_poll_handler

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    a9c9a6f741cd Merge tag 'scsi-misc' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14e6c8cd300000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c84ed2c3f57ace
dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=137a45a3300000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=105ba169300000

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

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 1 PID: 8812 Comm: iou-sqp-8804 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:vfs_poll include/linux/poll.h:88 [inline]
RIP: 0010:__io_arm_poll_handler+0x2fa/0xb10 fs/io_uring.c:5476
Code: 24 38 42 80 3c 20 00 74 08 48 89 ef e8 df 15 db ff 48 8b 6d 00 48 8d 5d 28 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 b8 15 db ff 4c 8b 23 49 83 c4 48 4c
RSP: 0018:ffffc90001e7f0a8 EFLAGS: 00010206
RAX: 0000000000000005 RBX: 0000000000000028 RCX: dffffc0000000000
RDX: 0000000000000010 RSI: 0000000000000000 RDI: ffffc90001e7f1f0
RBP: 0000000000000000 R08: dffffc0000000000 R09: ffff88801252e820
R10: ffffed10024a5d06 R11: 0000000000000000 R12: dffffc0000000000
R13: 1ffff920003cfe3f R14: ffffc90001e7f1fc R15: ffffc90001e7f1f8
FS:  00007f6951c24700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000049a01d CR3: 000000002b182000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 io_poll_add+0xf1/0x590 fs/io_uring.c:5751
 io_issue_sqe+0x192b/0x9280 fs/io_uring.c:6569
 __io_queue_sqe+0xe3/0x1000 fs/io_uring.c:6864
 tctx_task_work+0x2ad/0x560 fs/io_uring.c:2143
 task_work_run+0x146/0x1c0 kernel/task_work.c:164
 tracehook_notify_signal include/linux/tracehook.h:212 [inline]
 io_run_task_work+0x110/0x140 fs/io_uring.c:2403
 io_sq_thread+0xb5e/0x1220 fs/io_uring.c:7337
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
Modules linked in:
---[ end trace 65dffd9e454d7c44 ]---
RIP: 0010:vfs_poll include/linux/poll.h:88 [inline]
RIP: 0010:__io_arm_poll_handler+0x2fa/0xb10 fs/io_uring.c:5476
Code: 24 38 42 80 3c 20 00 74 08 48 89 ef e8 df 15 db ff 48 8b 6d 00 48 8d 5d 28 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 b8 15 db ff 4c 8b 23 49 83 c4 48 4c
RSP: 0018:ffffc90001e7f0a8 EFLAGS: 00010206
RAX: 0000000000000005 RBX: 0000000000000028 RCX: dffffc0000000000
RDX: 0000000000000010 RSI: 0000000000000000 RDI: ffffc90001e7f1f0
RBP: 0000000000000000 R08: dffffc0000000000 R09: ffff88801252e820
R10: ffffed10024a5d06 R11: 0000000000000000 R12: dffffc0000000000
R13: 1ffff920003cfe3f R14: ffffc90001e7f1fc R15: ffffc90001e7f1f8
FS:  00007f6951c24700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd472d29c0 CR3: 000000002b182000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0:	24 38                	and    $0x38,%al
   2:	42 80 3c 20 00       	cmpb   $0x0,(%rax,%r12,1)
   7:	74 08                	je     0x11
   9:	48 89 ef             	mov    %rbp,%rdi
   c:	e8 df 15 db ff       	callq  0xffdb15f0
  11:	48 8b 6d 00          	mov    0x0(%rbp),%rbp
  15:	48 8d 5d 28          	lea    0x28(%rbp),%rbx
  19:	48 89 d8             	mov    %rbx,%rax
  1c:	48 c1 e8 03          	shr    $0x3,%rax
  20:	48 b9 00 00 00 00 00 	movabs $0xdffffc0000000000,%rcx
  27:	fc ff df
* 2a:	80 3c 08 00          	cmpb   $0x0,(%rax,%rcx,1) <-- trapping instruction
  2e:	74 08                	je     0x38
  30:	48 89 df             	mov    %rbx,%rdi
  33:	e8 b8 15 db ff       	callq  0xffdb15f0
  38:	4c 8b 23             	mov    (%rbx),%r12
  3b:	49 83 c4 48          	add    $0x48,%r12
  3f:	4c                   	rex.WR


---
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.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [syzbot] general protection fault in __io_arm_poll_handler

[Jens Axboe]

On 9/3/21 2:28 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    a9c9a6f741cd Merge tag 'scsi-misc' of git://git.kernel.org..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14e6c8cd300000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c84ed2c3f57ace
> dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
> compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=137a45a3300000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=105ba169300000

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

-- 
Jens Axboe

Re: [syzbot] general protection fault in __io_arm_poll_handler

[syzbot]

Hello,

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

Reported-and-tested-by: syzbot+ba74b85fa15fd7a96437@syzkaller.appspotmail.com

Tested on:

commit:         31efe48e io_uring: fix possible poll event lost in mul..
git tree:       git://git.kernel.dk/linux-block for-5.15/io_uring
kernel config:  https://syzkaller.appspot.com/x/.config?x=914bb805fa8e8da9
dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1

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

Re: [syzbot] general protection fault in __io_arm_poll_handler

[Jens Axboe]

On 9/3/21 5:47 PM, syzbot wrote:
> Hello,
> 
> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
> 
> Reported-and-tested-by: syzbot+ba74b85fa15fd7a96437@syzkaller.appspotmail.com
> 
> Tested on:
> 
> commit:         31efe48e io_uring: fix possible poll event lost in mul..
> git tree:       git://git.kernel.dk/linux-block for-5.15/io_uring
> kernel config:  https://syzkaller.appspot.com/x/.config?x=914bb805fa8e8da9
> dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
> compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1
> 
> Note: testing is done by a robot and is best-effort only.

Dmitry, I wonder if there's a way to have syzbot know about what it's
testing and be able to run the pending patches for that tree? I think
we're up to 4 reports now that are all just fallout from the same bug,
and where a patch has been queued up for a few days. Since they all look
different, I can't fault syzbot for thinking they are different, even if
they have the same root cause.

Any way we can make this situation better? I can't keep replying that we
should test the current branch, and it'd be a shame to have a ton of
dupes.

-- 
Jens Axboe

Re: [syzbot] general protection fault in __io_arm_poll_handler

[syzbot]

syzbot has bisected this issue to:

commit 884a76881fc5f5c9c04de1b640bed2c340929842
Author: David Howells <dhowells@redhat.com>
Date:   Mon Feb 10 10:00:22 2020 +0000

    fscache: Procfile to display cookies

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=114e665d300000
start commit:   a9c9a6f741cd Merge tag 'scsi-misc' of git://git.kernel.org..
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=134e665d300000
console output: https://syzkaller.appspot.com/x/log.txt?x=154e665d300000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c84ed2c3f57ace
dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=137a45a3300000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=105ba169300000

Reported-by: syzbot+ba74b85fa15fd7a96437@syzkaller.appspotmail.com
Fixes: 884a76881fc5 ("fscache: Procfile to display cookies")

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

Re: [syzbot] general protection fault in __io_arm_poll_handler

[Dmitry Vyukov]

On Sat, 4 Sept 2021 at 02:49, Jens Axboe <axboe@kernel.dk> wrote:
>
> On 9/3/21 5:47 PM, syzbot wrote:
> > Hello,
> >
> > syzbot has tested the proposed patch and the reproducer did not trigger any issue:
> >
> > Reported-and-tested-by: syzbot+ba74b85fa15fd7a96437@syzkaller.appspotmail.com
> >
> > Tested on:
> >
> > commit:         31efe48e io_uring: fix possible poll event lost in mul..
> > git tree:       git://git.kernel.dk/linux-block for-5.15/io_uring
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=914bb805fa8e8da9
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
> > compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1
> >
> > Note: testing is done by a robot and is best-effort only.
>
> Dmitry, I wonder if there's a way to have syzbot know about what it's
> testing and be able to run the pending patches for that tree? I think
> we're up to 4 reports now that are all just fallout from the same bug,
> and where a patch has been queued up for a few days. Since they all look
> different, I can't fault syzbot for thinking they are different, even if
> they have the same root cause.
>
> Any way we can make this situation better? I can't keep replying that we
> should test the current branch, and it'd be a shame to have a ton of
> dupes.

Hi Jens,

This somehow fell through the cracks, but better late than never.

We could set up a syzbot instance for the io-uring tree.
It won't solve the problem directly, but if the branch contains both
new development ("for-next") and fixes, it will have good chances of
discovering issues before they reach mainline and spread to other
trees.
Do you think it's a good idea? Is there a branch that contains new
development and fixes?

Re: [syzbot] general protection fault in __io_arm_poll_handler

[Jens Axboe]

On 5/20/22 2:41 AM, Dmitry Vyukov wrote:
> On Sat, 4 Sept 2021 at 02:49, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 9/3/21 5:47 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
>>>
>>> Reported-and-tested-by: syzbot+ba74b85fa15fd7a96437@syzkaller.appspotmail.com
>>>
>>> Tested on:
>>>
>>> commit:         31efe48e io_uring: fix possible poll event lost in mul..
>>> git tree:       git://git.kernel.dk/linux-block for-5.15/io_uring
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=914bb805fa8e8da9
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=ba74b85fa15fd7a96437
>>> compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.1
>>>
>>> Note: testing is done by a robot and is best-effort only.
>>
>> Dmitry, I wonder if there's a way to have syzbot know about what it's
>> testing and be able to run the pending patches for that tree? I think
>> we're up to 4 reports now that are all just fallout from the same bug,
>> and where a patch has been queued up for a few days. Since they all look
>> different, I can't fault syzbot for thinking they are different, even if
>> they have the same root cause.
>>
>> Any way we can make this situation better? I can't keep replying that we
>> should test the current branch, and it'd be a shame to have a ton of
>> dupes.
> 
> Hi Jens,
> 
> This somehow fell through the cracks, but better late than never.
> 
> We could set up a syzbot instance for the io-uring tree.
> It won't solve the problem directly, but if the branch contains both
> new development ("for-next") and fixes, it will have good chances of
> discovering issues before they reach mainline and spread to other
> trees.
> Do you think it's a good idea? Is there a branch that contains new
> development and fixes?

My for-next stuff is always in linux-next, so I think as long as that is
tested, that should be quite fine. It's _usually_ not a problem, it just
sometimes happens that a broken patch ends up triggering a bunch of
different things. And then we don't get them all attributed in a fix, or
perhaps the patch itself is fixed up (or removed) and pushed out, then
leaving the syzbot reports in limbo.

In short, I don't think we need to do anything special here for now.

-- 
Jens Axboe