linux-kernel - Re: KASAN: use-after-free Read in hiddev

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, 27 Jan 2020 15:34:32 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        syzkaller <syzkaller@...glegroups.com>
Cc:     Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+106b378813251e52fc5e@...kaller.appspotmail.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: KASAN: use-after-free Read in hiddev_disconnect

On Mon, Jan 27, 2020 at 10:29 AM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> I already fixed this bug in an earlier thread.
>
> Syzbot always reports a use after free as two separate bugs, a read
> after free and a write after free.  It's too much hassle to mark all
> the duplicates.

+syzkaller mailing list

Hi Dan,

Not that it happens always, but, yes, it happens for racy bugs (for
single-threaded the type of the first access is usually
deterministic). Worse, sometimes they show up as GPF, unable to handle
kernel paging request, null-ptr-deref, user-memory-access, especially
for crashes that happen very frequently so that syzbot starts catching
long tail of more weird/unlucky incarnations.

The exact string is under our full control and can be changed. We did
some refinements to strings/grouping lots of times. I considered if
all of these should be grouped together and reported just as, say,
"bad-access in [function name]". However, the problem is that changes
to the strings/grouping will affect _all_ existing bugs: they will be
re-reported under new names, then old will be suspected to be fixed
(stopped happening), fix bisected, some closed as obsolete, some
concluded to be still happening, etc. And we have 300+ for upstream
(https://syzkaller.appspot.com/upstream) + 4 LTS versions + 4 Android
versions + a bunch of internal kernels + all users of syzkaller for
linux out there. So this will produce a whole lot of churn for
hundreds of people. The ones that we changed just affected
significantly fewer bugs (e.g. a new bug type).

I don't know what's the right solution at this point...
Changing the title will include lots of churn.
Marking as dups is too much hassle.
Not marking as dups will lead to hundreds of lots bugs and/or lots of
wasted time for people to rescan list of open bugs again and again,
missed backports, etc.