From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 29EC32FDC20 for ; Fri, 16 Jan 2026 11:54:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768564469; cv=none; b=uW01GnpMsbRE2Pb4HxfUM+eZATYmhPQQYjhZaQiNhf7MVSaexX4T33gN9V0AMpZpjn6S/Xi5LTxknPSs5JzbAVK7qb736aTaRUd7Im9Lxvs+PaBaNMkkJ928mRMeZTzFjpDFFMiO99zQ/eVBHddWdLpWU7VuTbE94wrFRnEykfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768564469; c=relaxed/simple; bh=TkjIGHJ6Iyr1KIGcy3UAbp+zf2iIzWl3TdScy37jNIg=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=hkxI9gfhnHlZDS37t1K16tHW4mCDen8jmzzDxINhrXks8/48Oo9UXToqsIljep89CYEkSOWvSNmA+hOhq7uDS6RRI24CM6d/Y85tlQGBf5ek9F+7Y/2QZ7oarnQGczGB1JN9VhpH1R1Zp1ij4L3EgcgEpPR0L75Imhyhbk0M+sg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WO0dgt5B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WO0dgt5B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74BF8C16AAE; Fri, 16 Jan 2026 11:54:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768564468; bh=TkjIGHJ6Iyr1KIGcy3UAbp+zf2iIzWl3TdScy37jNIg=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=WO0dgt5BYP1l+kuDoXDNb7uAqf9aV2fsvHFF/Z6mo0oQKqoU6bQCcF+HE643Hio5e DO4rpmPZrz7BwekVGM0YpuugWqzLPoyfP5Bw48CmbOtCT+nGsoYI8rVxV55KaQfBe4 cFo2F7f7kySLxZgy2sdKSLvXIbKXQMsidOIOtrjVxPWR88ZlnGEfzORUngccNY7St2 YK0XTBGfJQN5G1bZGeBvLpye/0XSENNu6sPZRVA3JTmsMZbuiIsXEkbT4qFSBjgngQ 3XxRsN4bSMvOhWXJugGri6QsxDgQPDeZfO1DX9sKsEibNH0zUSpRYCaSIqTapDTXu9 w0B2TM3GN7IVQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 16 Jan 2026 12:54:25 +0100 Message-Id: Cc: , , , , "Qiu-ji Chen" To: "Gui-Dong Han" From: "Danilo Krummrich" Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device() References: <20260113162843.12712-1-hanguidong02@gmail.com> In-Reply-To: <20260113162843.12712-1-hanguidong02@gmail.com> On Tue Jan 13, 2026 at 5:28 PM CET, Gui-Dong Han wrote: > Currently, driver_match_device() is called from three sites. One site > (__device_attach_driver) holds device_lock(dev), but the other two > (bind_store and __driver_attach) do not. This inconsistency means that > bus match() callbacks are not guaranteed to be called with the lock > held. > > Fix this by introducing driver_match_device_locked(), which guarantees > holding the device lock using a scoped guard. Replace the unlocked calls > in bind_store() and __driver_attach() with this new helper. Also add a > lock assertion to driver_match_device() to enforce this guarantee. > > This consistency also fixes a known race condition. The driver_override > implementation relies on the device_lock, so the missing lock led to the > use-after-free (UAF) reported in Bugzilla for buses using this field. > > Stress testing the two newly locked paths for 24 hours with > CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence > and no lockdep warnings. > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220789 > Suggested-by: Qiu-ji Chen > Signed-off-by: Gui-Dong Han Applied to driver-core-linus, thanks!