From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45CF6C432C0 for ; Tue, 19 Nov 2019 23:03:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 28D1B2245C for ; Tue, 19 Nov 2019 23:03:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727394AbfKSXDD convert rfc822-to-8bit (ORCPT ); Tue, 19 Nov 2019 18:03:03 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:45762 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727329AbfKSXDD (ORCPT ); Tue, 19 Nov 2019 18:03:03 -0500 Received: from marcel-macbook.fritz.box (p4FF9F0D1.dip0.t-ipconnect.de [79.249.240.209]) by mail.holtmann.org (Postfix) with ESMTPSA id 816E8CECFA; Wed, 20 Nov 2019 00:12:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: general protection fault in kernfs_add_one From: Marcel Holtmann In-Reply-To: Date: Wed, 20 Nov 2019 00:03:00 +0100 Cc: syzbot , Johan Hedberg , "David S. Miller" , Benjamin Herrenschmidt , Greg Kroah-Hartman , Linux Kernel Mailing List , Rafael Wysocki , syzkaller-bugs , Tejun Heo , linux-bluetooth Content-Transfer-Encoding: 8BIT Message-Id: References: <000000000000bf6bd30575fec528@google.com> <000000000000e2ac670597ad2663@google.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3601.0.10) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Linus, > 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? long time ago there used to be an issue with quick device remove / device add operations, but that was fixed. I am just too fuzzy on the details since it has been a while. We also haven’t touched our sysfs integration in a while and Bluetooth support is so old that this might have been bit-rotting. I need to run the re-producer myself and see if something stands out that I can spot. Regards Marcel