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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACT4Y+ZW0Z7KzWD4sURfPLga4CcdeVaO_wxTF9=Cz_TeR=TDNA@mail.gmail.com>
Date:   Tue, 13 Oct 2020 12:35:45 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Arnd Bergmann <arnd@...db.de>
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:51 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> 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.

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.