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 E04C72749C7 for ; Tue, 13 Jan 2026 19:23:23 +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=1768332204; cv=none; b=Qn2jE3/+vNBSgI1BCmduhDKsXpmui1/YRfca6hFohbHf5h89j9KtOStxOj6dbgOsjfYAAntRY9kWTXnqwf6idkaF5llnAzg4JOuQmf6cOjq6uWaFRBvyPV51f1nDccFH7cGjGoailtTzYiwFT4i22KhCWKO32ZMRyXOS8akHvus= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768332204; c=relaxed/simple; bh=6/PX02B1h3QbHoI9HzJT9+AQpgwmXfEs5ATJ9SIpppo=; h=Mime-Version:Content-Type:Date:Message-Id:To:From:Subject:Cc: References:In-Reply-To; b=EDr2L2s7Zfn2v9yYNX13F0zdZpMxyUwOqQPHmrhXjpGT4VgAPk9eJrwQiDpxiJCz0XtkFl30JwMFDVb5KfIRIW21yCX1BaL4YvDXt6eWr7Ce+r7YwNsK/qMbf7lqgIeNc6o29F7QlRhhT6cl4yBq1sNjPfuhes/Lav/n6XA7bTQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pochwmYN; 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="pochwmYN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 486BBC116C6; Tue, 13 Jan 2026 19:23:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768332203; bh=6/PX02B1h3QbHoI9HzJT9+AQpgwmXfEs5ATJ9SIpppo=; h=Date:To:From:Subject:Cc:References:In-Reply-To:From; b=pochwmYNs2KG+YRfbQ+OCDvbc94ve0hCCwbjcQr28SwCWYUqXJn2XBnan3zNZI9kU 7uN4kiBM5gbJwc17QgfhrWCrH9VTSvYYNISc+Y/sokVvfGVUUbGE0oum4DtLY7lwGw WTrez7g+RpVaxeD4183qNeGQ4fqZalU+Z3n3Ag/axcrrlrROLjF5kNEL4NOKEiuP/l Y8pv+1Ah/W9fwl/7AcQ6GHg7beOonWKxSQLCCV7qAWtVOLocBSAGi4t7ZsAxysYLCg fXNLl23GCmZLBENoa39HoVePqbkPiKaD9IEHTcK9URiOa2ca9lW1xLYUKFHUhk3Zf2 5kC5b++V5+MZA== 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: Tue, 13 Jan 2026 20:23:20 +0100 Message-Id: To: "Gui-Dong Han" From: "Danilo Krummrich" Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device() Cc: , , , , "Qiu-ji Chen" 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 Fixes: 49b420a13ff9 ("driver core: check bus->match without holding device = lock") > Suggested-by: Qiu-ji Chen > Signed-off-by: Gui-Dong Han This looks good now! Reviewed-by: Danilo Krummrich