linux-kernel - Re: general protection fault in usb_find_alt

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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 23 Sep 2018 17:15:30 -0400 (EDT)
From:   Vladis Dronov <vdronov@...hat.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot 
        <bot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@...kaller.appspotmail.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Johan Hovold <johan@...nel.org>,
        kai heng feng <kai.heng.feng@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>
Subject: Re: general protection fault in usb_find_alt_setting

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@...kaller.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@...kaller.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@...gle.com>
> To: "Vladis Dronov" <vdronov@...hat.com>
> Cc: "syzbot" <bot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2f31@...kaller.appspotmail.com>, "syzkaller-bugs"
> <syzkaller-bugs@...glegroups.com>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Johan Hovold"
> <johan@...nel.org>, "kai heng feng" <kai.heng.feng@...onical.com>, "LKML" <linux-kernel@...r.kernel.org>, "USB list"
> <linux-usb@...r.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@...hat.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.