From: Vladis Dronov <vdronov@redhat.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot
<bot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@syzkaller.appspotmail.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johan Hovold <johan@kernel.org>,
kai heng feng <kai.heng.feng@canonical.com>,
LKML <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: general protection fault in usb_find_alt_setting
Date: Sun, 23 Sep 2018 17:15:30 -0400 (EDT) [thread overview]
Message-ID: <348002473.15454693.1537737330932.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CACT4Y+anBfjFnKget7zu75uZVOV6ZT3-RPshaVt2a_4R3ararg@mail.gmail.com>
Hello, Dmitry,
Thank you for the reply. I probably do not properly understand how
syzcaller works then. Can you please, have a look at my reasoning.
The bug:
https://syzkaller.appspot.com/bug?id=4b88ff5aa6aa88f9283a45cc62f16e55b0722131
(Reported-by: syzbot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@syzkaller.appspotmail.com,
"[upstream] general protection fault in usb_find_alt_setting")
was not fixed. it was closed as invalid, so, afaiu, all the work has stopped for it.
So syzbot did not wait until the fixing commit reached all tested trees, and the
crash was not spotted again _after_ that.
Then I look at the bug:
https://syzkaller.appspot.com/bug?id=a0ec6260a1d37288a4508250fe30a5604ceec666
(Reported-by: syzbot+19c3aaef85a89d451eac@syzkaller.appspotmail.com,
"[upstream] general protection fault in usb_find_alt_setting (2)")
And I see the crash happens at the same place _and_ at the same code:
(bug id=a0ec6260a1d3)
RIP: 0010:usb_find_alt_setting+0x38/0x310 drivers/usb/core/usb.c:231
Code: ... fd 48 8d 7b 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 86 02 00 00
(bug id=4b88ff5aa6aa)
Code: ... fd 48 8d 7b 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 a1 02 00
RIP: usb_find_alt_setting+0x38/0x310 drivers/usb/core/usb.c:231 RSP: ffff88005893f610
This makes me be sure these are the same bug (dup) which are fixed by the same
commit "USB: handle NULL config in usb_find_alt_setting()".
As I'm kinda a perfectionist, I would like to mark (bug id=4b88ff5aa6aa) as
fixed by this commit and not closed as invalid.
Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer
----- Original Message -----
> From: "Dmitry Vyukov" <dvyukov@google.com>
> To: "Vladis Dronov" <vdronov@redhat.com>
> Cc: "syzbot" <bot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@syzkaller.appspotmail.com>, "syzkaller-bugs"
> <syzkaller-bugs@googlegroups.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Johan Hovold"
> <johan@kernel.org>, "kai heng feng" <kai.heng.feng@canonical.com>, "LKML" <linux-kernel@vger.kernel.org>, "USB list"
> <linux-usb@vger.kernel.org>
> Sent: Sunday, September 23, 2018 6:27:24 PM
> Subject: Re: general protection fault in usb_find_alt_setting
>
> On Sun, Sep 23, 2018 at 11:11 AM, Vladis Dronov <vdronov@redhat.com> wrote:
> > #syz fix: USB: handle NULL config in usb_find_alt_setting()
> > #syz dup: general protection fault in usb_find_alt_setting (2)
>
> Same here.
> syzbot process designed in such way that it will not open second
> version of the bug (2) for the same bug. syzbot waits until the fixing
> commit reaches all tested tree and only then closes a bug. If the
> crash is spotted again _after_ that, then syzbot creates second
> version of the bug (2). But at that point it has to be a different bug
> requiring a different fix.
> So this should not be a dup, and should not fixed with the same commit
> as the first version.
next prev parent reply other threads:[~2018-09-23 21:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <956405482.15417289.1537693839327.JavaMail.zimbra@redhat.com>
[not found] ` <1722725855.15417291.1537693865632.JavaMail.zimbra@redhat.com>
2018-09-23 16:27 ` Dmitry Vyukov
2018-09-23 21:15 ` Vladis Dronov [this message]
2018-09-24 13:15 ` Dmitry Vyukov
[not found] <94eb2c05b4ba7e98d2055dc57696@google.com>
2018-05-11 17:39 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=348002473.15454693.1537737330932.JavaMail.zimbra@redhat.com \
--to=vdronov@redhat.com \
--cc=bot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@syzkaller.appspotmail.com \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome