general protection fault in qp_release_pages

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 3dd0130f Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1219a8e8500000
kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
dashboard link: https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113937fb900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1049031b900000

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d57007900000
final oops: https://syzkaller.appspot.com/x/report.txt?x=11d57007900000
console output: https://syzkaller.appspot.com/x/log.txt?x=16d57007900000

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

general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 6894 Comm: syz-executor291 Not tainted 5.9.0-rc8-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:compound_head include/linux/page-flags.h:182 [inline]
RIP: 0010:put_page include/linux/mm.h:1172 [inline]
RIP: 0010:qp_release_pages+0x5a/0x310 drivers/misc/vmw_vmci/vmci_queue_pair.c:635
Code: 5c ad d1 fc 4d 85 f6 c7 44 24 04 00 00 00 00 0f 85 0f 01 00 00 e9 27 02 00 00 e8 c1 b0 d1 fc 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 62 02 00 00 48 8b 45 08 31 ff 49 89 c4 48 89
RSP: 0018:ffffc900014e7948 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff8880a06990d0 RCX: ffffffff84a48f81
RDX: ffff88808e3ec300 RSI: ffffffff84a48e4f RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000001 R09: ffff8880960634ff
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffd
R13: dffffc0000000000 R14: fffffffffffffff2 R15: 0000000000000000
FS: 0000000001e5e880(0000) GS:ffff8880ae500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 00000000a1e74000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
qp_host_get_user_memory+0x249/0x3e0 drivers/misc/vmw_vmci/vmci_queue_pair.c:660
qp_host_register_user_memory drivers/misc/vmw_vmci/vmci_queue_pair.c:704 [inline]
qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1383 [inline]
qp_broker_alloc+0x10f9/0x1bf0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1737
vmci_qp_broker_alloc+0x48/0x60 drivers/misc/vmw_vmci/vmci_queue_pair.c:1930
vmci_host_do_alloc_queuepair.constprop.0+0x1b4/0x400 drivers/misc/vmw_vmci/vmci_host.c:488
vmci_host_unlocked_ioctl+0x13cc/0x1e60 drivers/misc/vmw_vmci/vmci_host.c:927
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4402f9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd6af99eb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004402f9
RDX: 0000000020000100 RSI: 00000000000007a8 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000246 R12: 0000000000401b00
R13: 0000000000401b90 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 5d73c037702bf45c ]---
RIP: 0010:compound_head include/linux/page-flags.h:182 [inline]
RIP: 0010:put_page include/linux/mm.h:1172 [inline]
RIP: 0010:qp_release_pages+0x5a/0x310 drivers/misc/vmw_vmci/vmci_queue_pair.c:635
Code: 5c ad d1 fc 4d 85 f6 c7 44 24 04 00 00 00 00 0f 85 0f 01 00 00 e9 27 02 00 00 e8 c1 b0 d1 fc 48 8d 7d 08 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 62 02 00 00 48 8b 45 08 31 ff 49 89 c4 48 89
RSP: 0018:ffffc900014e7948 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff8880a06990d0 RCX: ffffffff84a48f81
RDX: ffff88808e3ec300 RSI: ffffffff84a48e4f RDI: 0000000000000008
RBP: 0000000000000000 R08: 0000000000000001 R09: ffff8880960634ff
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffd
R13: dffffc0000000000 R14: fffffffffffffff2 R15: 0000000000000000
FS: 0000000001e5e880(0000) GS:ffff8880ae500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 00000000a1e74000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


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

[Arnd Bergmann]

On Mon, Oct 12, 2020 at 8:11 AM syzbot
<syzbot+f58fe4...@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 3dd0130f Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1219a8e8500000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
> dashboard link: https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113937fb900000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1049031b900000
>
> Bisection is inconclusive: the issue happens on the oldest tested release.
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d57007900000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=11d57007900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=16d57007900000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f58fe4...@syzkaller.appspotmail.com
>

I looked at this for a bit, and I think there is a missing range check
for one of the
members of 'struct vmci_qp_alloc_info' somewhere in the ioctl path.

https://syzkaller.appspot.com/x/repro.c?x=1049031b900000 shows what
arguments get passed, and while all the members are small, my guess is
that something is wrong with the sizes in qp_host_alloc_queue() allocating
an array based on produce_size/consume_size, while
qp_host_register_user_memory() bases the size on the larger
ppn_va/num_ppns.

Adding everyone from the git history that did meaningful changes in the past
for this driver, as there is no specific maintainer file entry for
them to further
investigate.

Arnd

[Dmitry Vyukov]

Hi Arnd,

There is already a recorded fix for this on the dashboard:
https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
VMCI: check return value of get_user_pages_fast() for errors

> --
> 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-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAK8P3a3p7Ueydagr4yshr8RKGzLivJZwEh0TxfipuHYRkN9Wcw%40mail.gmail.com.

[Arnd Bergmann]

On Mon, Oct 12, 2020 at 10:14 AM Dmitry Vyukov <dvy...@google.com> wrote:
> On Mon, Oct 12, 2020 at 10:01 AM Arnd Bergmann <ar...@arndb.de> wrote:
> > On Mon, Oct 12, 2020 at 8:11 AM syzbot
> >

> > Adding everyone from the git history that did meaningful changes in the past
> > for this driver, as there is no specific maintainer file entry for
> > them to further
> > investigate.
>
> Hi Arnd,
>
> There is already a recorded fix for this on the dashboard:

Ok, good.

> https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
> VMCI: check return value of get_user_pages_fast() for errors

Ah, I actually looked at linux-next, which included the fix. I had
never before looked at the dashboard, good to know where to find
this information.

If this is something that happened to others as well, could the
email report be changed to point out bugs that are already
fixed in linux-next but not in mainline?

Arnd

[Dmitry Vyukov]

When syzbot mails a report, it does not know about any fixes by definition.

There is a pending feature request to notify when a fix becomes known:
https://github.com/google/syzkaller/issues/1574

However:
1. This will double the number of emails from syzbot, not sure if it
will be welcome.
2. This probably only makes sense for fixes that are auto-discovered
in git trees. While this one came from a user email, it was just not
sent to the same thread/recipients (the common problem of replying to
emails you did not receive). So it would not help in this case.
3. There is lots of other dynamic info on the dashboard (more crashes,
where it happens, how frequently, when started/stopped). It's not
feasible to send an email for every update (there can be 100K
crashes), so the dashboard needed to be looked at in some cases
anyway.

Do you see any potential improvements in this context?

[Arnd Bergmann]

On Mon, Oct 12, 2020 at 11:29 AM Dmitry Vyukov <dvy...@google.com> wrote:
> On Mon, Oct 12, 2020 at 11:16 AM Arnd Bergmann <ar...@arndb.de> wrote:
> > > There is already a recorded fix for this on the dashboard:
> >
> > Ok, good.
> >
> > > https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
> > > VMCI: check return value of get_user_pages_fast() for errors
> >
> > Ah, I actually looked at linux-next, which included the fix. I had
> > never before looked at the dashboard, good to know where to find
> > this information.
> >
> > If this is something that happened to others as well, could the
> > email report be changed to point out bugs that are already
> > fixed in linux-next but not in mainline?
>
> When syzbot mails a report, it does not know about any fixes by definition.
>
> There is a pending feature request to notify when a fix becomes known:
> https://github.com/google/syzkaller/issues/1574

Ok, I see.

> However:
> 1. This will double the number of emails from syzbot, not sure if it
> will be welcome.

It's only doubled if you assume that all bugs get fixed, right?
Probably good to stay hopeful on that ;-)

> 2. This probably only makes sense for fixes that are auto-discovered
> in git trees. While this one came from a user email, it was just not
> sent to the same thread/recipients (the common problem of replying to
> emails you did not receive). So it would not help in this case.
> 3. There is lots of other dynamic info on the dashboard (more crashes,
> where it happens, how frequently, when started/stopped). It's not
> feasible to send an email for every update (there can be 100K
> crashes), so the dashboard needed to be looked at in some cases
> anyway.
>
> Do you see any potential improvements in this context?

I would personally prefer the extra emails here. Usually by the
time I decided to ignore a thread, getting more replies to it
doesn't bother me. I understand others may feel differently here.

Making the dashboard link more prominent, or pointing out in
the email that it can contain newer information might help,
though I probably would have missed that as well, as I tend
to look at the oops output first. This was the first time I recall
that I looked at the reproducer source, which I found very
useful, but had probably missed in the past as well.

Arnd

[Dmitry Vyukov]

Just to clarify you asking for syzbot to repeat all commands sent to
it? Basically a developer sends an email "this commit fixes this bug"
and syzbot will send another email saying "this commit fixes this
bug", right? Or something else?

> Making the dashboard link more prominent, or pointing out in
> the email that it can contain newer information might help,
> though I probably would have missed that as well, as I tend
> to look at the oops output first. This was the first time I recall
> that I looked at the reproducer source, which I found very
> useful, but had probably missed in the past as well.

I am not sure this is easily solvable problem.
If we include too much information into emails (also duplicated in
each of them), even fewer people will read walls of text. So anything
added to the text will just reduce the usefulness of existing info.
If we include too little info, people will not be aware of things. And
lots of kernel developers still say "I am opening any web pages". So
we need to include e.g. the kernel config.
Adding "walls of text" to explain every bit may be the opposite effect
as well. And we have a whole lot of potential info to include, see the
"more information about syzbot" link in every email.
Ted Ts'o specially suggested the current condensed/dry format. Once
one learns what's available/where, I can see how such a format is the
most handy one.

Having said that, if you have concrete suggestions on the format that
are not over-tailored to hindsight on this particular case/person, and
that balances between having too much/little info, that's welcome.