linux-kernel - Re: general protection fault in qp_release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Oct 2020 11:51:15 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzkaller <syzkaller@...glegroups.com>, rgerganov@...are.com,
        syzbot <syzbot+f58fe4bb535845237057@...kaller.appspotmail.com>,
        gregkh <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: general protection fault in qp_release_pages

On Mon, Oct 12, 2020 at 11:29 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Mon, Oct 12, 2020 at 11:16 AM Arnd Bergmann <arnd@...db.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