From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E9964E2F00 for ; Fri, 9 Oct 2026 14:19:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791555593; cv=none; b=E2RYXEbkfB3SX6KCYi7QWYzXOb63opuo2V129uzd3rM1+Utju1ghvt/gHO3c2PDAnhPWikoin9OVySzfBB4Tlq4vnoFI4EjBiZ/waxsu3Ft077+SThYVuwvFUmuuuPLi5aM477bGDdWxrC/dM+cTK2KMVLoEVrnXs0lcGjESy00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791555593; c=relaxed/simple; bh=AGVPjqicrTax98tPY6K/BUxJ7u2Bc/hgEP7b6d2MePY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NpFh1gdhFabXBfkUr168BlM/WepN33Of9aGH3dvGNaZohXwvtHt8rnOeDRuAXSJy8OBlaAWAx56KsSraWakBLgdFe+elr7Fz0zOTMzSq5nec4OjCFmn0khF2x3sjOy26dszELxpBRReRtLcgH0kNmWT28xfUJ3DlHLuB6QmcDbs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fastmail.org; spf=pass smtp.mailfrom=fastmail.org; dkim=pass (2048-bit key) header.d=fastmail.org header.i=@fastmail.org header.b=DX7vyj/K; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=NttPwU+t; arc=none smtp.client-ip=103.168.172.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fastmail.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fastmail.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fastmail.org header.i=@fastmail.org header.b="DX7vyj/K"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="NttPwU+t" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 4D242140010E for ; Fri, 9 Oct 2026 10:19:48 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Fri, 09 Oct 2026 10:19:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1791555588; x=1791641988; bh=AGVPjqicrT ax98tPY6K/BUxJ7u2Bc/hgEP7b6d2MePY=; b=DX7vyj/K63yNh08WPbwdA2aFDU 0/c+kyQxW7yXleo5FRM8LLYFQJHFQU0mV4UcYu8eOIhNbFlfP3FzPvzHUgDv/8MP PU8hcVjj6anaas7B4hyyVrmbmiyVBEW47+k/rtky5mKKarije8SqikVp1ACXa7bo diJw0v6Krb/jfa6PjT0njdLaUIH1NLAfhonyohpZkRGR/tu28IrA+BkBWExGTey6 Y7kw1WGoaHx0svKliqx/L52EcqbS4YO8WcgaCw/edi50kMxw+VTtCZGFRyXAMV+H boEmTHRlAm57oGFsVBZUDJNJJlLFa9wmmouE/jwwVn4nwAfM4vJNxPt11Xdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1791555588; x=1791641988; bh=AGVPjqicrTax98tPY6K/BUxJ7u2Bc/hgEP7 b6d2MePY=; b=NttPwU+tlr67ygR3H/k7t1PSBdyz0EaQ8u3m5Ut2/ROY5NKROny GJdFXTxATg1B8nNj4VQq/OGMXPj/ynVRwm3WuZbyRL9gfZkhLUbAjIKLR7yFPUA1 BNV3IZQmoOZNJzXEwpckjGztBUTzlSQGWP6FHLNsX8EoUgak4EUvFKH4sybwBpGi EhTBfqzpJvgjihbc9Q6WrNBy8FUPJ8d5/rDMkPXnZQgEO9efx/8+HaHdyTBgeKmX zsww+dD+OrhcKwfqxiSEv5/O/Dtb0eU/yBraCIHWeZH+fziuyYQo1B28yBMiBQo1 RgdbsQe8V8UIPaG21peagmdhJKWtj0OxYTg== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=fastmail.org a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791555588; d=fastmail.org; mf=PGljYkBmYXN0bWFpbC5vcmc+; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm2:rsa-sha256:HO2P7stMh5efUUYZhLf1HgBR+HtiNxf6mBcVgGIG73vn7BP HxJ/nAUPeuQE3RkJX/LbLWCvHcZZYxfPY0mxT0v+yyIujFs404T5Mwel1TAqDbFT P584R5av1yodsLuvdPnry2x7eiPWSbiICPqqYzKut8HJ7P6UVq5VDKUnCGHj2mgU 8Nt66Ey2RayZxobVygECfwEKxfdAO3Zp1OkcoRBiLI9VgS2L/cSG4uJNxV39TG2k NdZCCH+8ZSfaMOD/Y/ycCvpv4WO8g0UVodGYi10iDlSjNvMXHRPO5wUwAC4rTzwa l/1LCvWaayDhxRjU9/IUUNsa9RH/omZEowWcTyQ==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-disposition,content-type,date,feedback-id,from, in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:c8bKZDb+nDxVxVOje5BAY7NFhfce6mHaLT1MhSKE+70=:AGVPjqicrTax98tPY6K/BUxJ7u2Bc/hgEP7b6d2MePY=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFo33oLHXN5YBNckb5fyYNOz6OBcIa8W6fUlslLcH4h/bv3An3xRCr2pXytzGRLiL pidtqkKaMgdsUXxcbbMWraoCVdgzSJZcFwtNVAmhBnPZbx8pDunQAO26IX8sAMg9D7QB8B Iu7fA6+Rc7vNi1BxZV4pjSzgtOvJIFcMZnaIHz+SXgNz80WUzMA01KGgasOqe5pwLTh4Hp Fr2FfT7XmF027h81n7WXi7zdekffC8BS1uHn0DUN9s//NK07tT837U6JvFfSXfbMMGa9Va qFXL1fe9/+5BDe9RodNk4uQs7zLWHo2dVS4W2ChFlnqhw3B2XImGnevk1gHqsfFQwu/Mt9 6j0EK7OoMPej96izC4+XWfhqpYaBbBvul8nzHph/LCbd7/YZaQfuDlsX07Xz9pZJorRe0m O0Pd60eN8/HQ9v1+b3BS+pgNQvo32NacOfxl39N4mIvVixXuEUfLVlQI89RVqunAtQn6Nx PQMp5AoIvEWbr83Cl+aFF3JhtRUfMS2X+nM9kxpTgnAFtVPTC6WIzBAB1gJuFdOuB7Wt4Q Qmf9dbTykakuwKpBZFSUfXn2I/QQYfApniXQHDcg0aau0j82UG9ZGG+eyzleEQjlqLzJBT YhmsOpDfCYgIewDu+EpqP+zXrzviXNKCrNlXTs7o2RJ3koDwh4Z0JRT1/PaQ X-ME-Proxy: Feedback-ID: ib53e4b78:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Oct 2026 10:19:47 -0400 (EDT) Date: Fri, 9 Oct 2026 09:19:45 -0500 From: Ian Bridges To: Quchaosheng Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , syzbot+3942dc5563ea8b96bbbe@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org, driver-core@lists.linux.dev, Luis Chamberlain , Russ Weight Subject: Re: [RFC PATCH] firmware_loader: fix use-after-free in fw_load_sysfs_fallback() Message-ID: References: <20260928065053.1750765-1-quchaosheng000406@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260928065053.1750765-1-quchaosheng000406@163.com> Hi Quchaosheng, Thanks for the review, and for measuring it rather than reasoning about it. The deadlock is real and this approach is a dead end, so I am withdrawing the patch. I reproduced it on a clean v7.0.1 with the RFC applied and CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y, using a platform driver whose probe() issues a synchronous request_firmware() for a missing file. The probe runs with device_lock(dev) already held, request_firmware() falls through to fw_load_sysfs_fallback(), and that takes device_lock(parent) on the same device. The task ends up in uninterruptible sleep in __mutex_lock, reached from fw_load_sysfs_fallback() inside request_firmware(), called from the driver's probe(), which really_probe() had entered after __device_attach() already took device_lock(dev). So it is the same mutex taken twice by the same task. request_firmware() never returns, and the firmware timeout never matters because the task is stuck on the mutex rather than waiting for userspace, exactly as you said. One thing worth mentioning for anyone reproducing this is that lockdep will not flag it. device_initialize() marks dev->mutex with lockdep_set_novalidate_class() in drivers/base/core.c, so PROVE_LOCKING cannot report the recursive acquisition. The silent hang is the only signature. The two paths do differ. The reported syzbot crash is the asynchronous request_firmware_nowait() path, where fw_load_sysfs_fallback() runs from a workqueue with no device_lock held. The lock I added sits in code that both callers share, so it serializes the async path but deadlocks the synchronous one. I do not think there is a one line fix here, which is the main reason I am not sending a v2. The underlying problem is that device_add() touches the requesting device's kernfs nodes in more than one place with nothing holding them alive, while device_del() frees them through a recursive teardown. sysfs_create_dir_ns() reads kobj->parent->sd and takes a reference on it before kernfs_add_one(). Then create_dir() takes another reference on kobj->sd after the add, by which point __kernfs_remove() on the parent can already have reaped the child that was just added. A kernfs_get_unless_zero() try-get in sysfs_create_dir_ns(), which was your direction (a), closes the first site but the fault just moves to the second. Covering every site means touching generic kobject and kernfs code, and serializing device_add() against the teardown cannot use the device mutex, as this deadlock shows, without blocking disconnect for the fallback timeout. As far as I can tell, this is really a driver core and kernfs design question, so I would rather not throw a third mechanism at it without a steer from the maintainers. Thanks, Ian