Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1124312ybc; Tue, 19 Nov 2019 15:04:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwsEgqVFx9cbqP4sV43U0Ghz8oYkxEEKNPujslVhyjxpuZuJQVghFsgUprspkAtn5N0LSlo X-Received: by 2002:a17:906:6043:: with SMTP id p3mr284811ejj.103.1574204646211; Tue, 19 Nov 2019 15:04:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574204646; cv=none; d=google.com; s=arc-20160816; b=KRpmoN2F44MSGAs0FB4LyKK49P4GQ6lIOKmzd6cKBNiM6dmdxl8783FkrNm0c+jrLr hx/KaXLjfblh4SymZLNOWbvJqa4p+s4lgzjM6QlwxNidl2svQgCpyL4ke2OBCvfYM9p7 9sLKh2DMRrThU/Q1PDj1lS1Z78ub5k/5lRqgaN8EZW1oS1wGdUhHIqGlbzPDb/Ioxn8n yUXBrlCz9w8sSibL09JqthyreLWvjepnVVnLkWAZSvfNF+QYV64nRV56SkuDEMTkfWvl mDDPwkHDg/Soi6iNctaSxRKlM2JtNMVM99wGll0J9erB/kwWTdgNNSI3R/WhaYvSCEeS n9Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=4hiIbml78kTfaRyo1S1TtA0udetJGkPZKrswUQIIzyo=; b=odIGWcxI5zdG/iX+Wz/JPJ6CjkDkvonIHcVA3ZadQREeto9eOEmicFIug0dpaB8sbt 4+GV0PUAtrXK2TbIuylvNtuograyEuebbdikZd8VCFLomyZvXs1UiJZPJyrs0hA9YXIy uW0nqrnxGfO0nMeYR6W8EqOp1lFsEvXaknS1dDB1w8hieygd9BsVBxn9reXXsAsmHNw4 VYiWwA45c3CXjdlD+IUy5zquhH4G5BW4dykVFiv0sEHODs93StDhe5SmQU0o7r4XVKeW RM+6eXBCmfDpr784fr9bshk64l2RUo4t008GsKr3HhFkPfA2YChhj+ro7YOdLevme8t5 XKXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si16265033edf.256.2019.11.19.15.03.22; Tue, 19 Nov 2019 15:04:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727385AbfKSXDD convert rfc822-to-8bit (ORCPT + 99 others); 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