linux-kernel - Re: general protection fault in kernfs_add

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]

Message-ID: <CAHk-=wjg0JXgwb6rkFK0q_JvW7YdGpiPtMVWe=YhFK1y_2-F7Q@mail.gmail.com>
Date:   Tue, 19 Nov 2019 11:00:11 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     syzbot <syzbot+db1637662f412ac0d556@...kaller.appspotmail.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rafael Wysocki <rafael@...nel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Tejun Heo <tj@...nel.org>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>
Subject: Re: general protection fault in kernfs_add_one

So looking at the decode, as usual the noise generated by KASAN isn't
being very helpful, but it does look like at least one of the reports
(I picked 5.2 because I don't care about 4.19 etc) is because
'kernfs_root(kn) is NULL in kernfs_add_one().

Looking at the reports, every single one seems to have a call chain
that comes from vhci_write() -> vhci_get_user() ->
vhci_create_device() -> __vhci_create_device() -> hci_register_dev()
-> device_add() -> kobject_add().

(In this case, "every single one" is by looking at the last 10 reports
sorted by date, it wasn't exhaustive).

The way it got into 'write()' can be a bit varied (splice, write, whatever).

That makes me think it's bluetooth that is the problem, but it might
be an effect of how syzbot groups the reports too, of course.

Might the device have been added at the same time that the last
previous device was removed, so that the parent was deleted as the new
device was aded? I dunno. The repro seem to be a repeated "open
/dev/vhci, write two random bytes to it"

Or might it be some "it happens after you've added enough devices that
something overflows" issue?

Adding bluetooth people to the cc.

                  Linus

On Mon, Nov 18, 2019 at 10:27 PM syzbot
<syzbot+db1637662f412ac0d556@...kaller.appspotmail.com> wrote:
>
> syzbot has bisected this bug to:
>
> commit 726e41097920a73e4c7c33385dcc0debb1281e18
> Author: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Date:   Tue Jul 10 00:29:10 2018 +0000
>
>      drivers: core: Remove glue dirs from sysfs earlier
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=168e1012e00000
> start commit:   5e335542 Merge branch 'for-linus' of git://git.kernel.org/..
> git tree:       upstream
> final crash:    https://syzkaller.appspot.com/x/report.txt?x=158e1012e00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=118e1012e00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=9917ff4b798e1a1e
> dashboard link: https://syzkaller.appspot.com/bug?extid=db1637662f412ac0d556
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10a66c11400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1346c771400000
>
> Reported-by: syzbot+db1637662f412ac0d556@...kaller.appspotmail.com
> Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection