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 6D39D318EF8 for ; Tue, 13 Jan 2026 11:09:01 +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=1768302541; cv=none; b=XMxOZdvL5TIrtG2phxSFVF9EViOsXhra0gHQBERhmI+IFDj5hvbRcodukyTYbCdirMh320hRmY5/RM0nhKuU0T5j1BhuI2ACNDHLrjHZj4I5ovGkijHp35ABHSbdbAh3bid3EiNSX09JG5BGU5EhHBwFAc5eOlO1jrTxG9N3TwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768302541; c=relaxed/simple; bh=xiF2Tfdy8bFRbKmIEK92FJbmW7DvBEYRGY3ObN9FkkQ=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=LU0x9gcjngrjL9C29+9IEpKNDvT5tn8qR+KiiuFXn+6yZVaYvT3Y4NQvVbjOpfgAJva4X6FKCPwMV4HO1VuHuJEWv/+pTzBLI/rCxhALbVQEtHjZuwzhZJ+bAU+mlo1Gc7/h0pEKUtb/E8Lw8fHv6A0GpkAswqmYlsrupp7f81k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l3qURRtd; 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="l3qURRtd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC87BC116C6; Tue, 13 Jan 2026 11:08:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768302541; bh=xiF2Tfdy8bFRbKmIEK92FJbmW7DvBEYRGY3ObN9FkkQ=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=l3qURRtd3MF4LuTN6NyBE0Fx+EGMYAQ4ZR6b8kAl4to7YUJPg+/aAZXFOCfuQ/rjE OjaxAL11XkjZvHuA33DSB0z/4pXp3TI36cD6ENyYus1mehKNCYq94kSPWNnmtMN+4w TY+evfRXl2ticm4EtxYes+bKft66ARCeeNKNFOOJSXg5KCOSnj9g8sV5mPmqPPSOaR aq+JQ29l3/OGKyGKj2oSadmvH/KEXhiUbtQCqMtMLeDMuegyUUSEx/sn5i3v2BqYXC quoMgiII9GMuURZ7l1wam9akGHIUhdmLWnjGeZzMmPKelxxrTLA3j4fJS6cKLespin TcpVgH/SQEc+g== 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 12:08:58 +0100 Message-Id: Subject: Re: [PATCH v3] driver core: fix use-after-free of driver_override via driver_match_device() Cc: , , , , "Qiu-ji Chen" To: "Gui-Dong Han" From: "Danilo Krummrich" References: <20251127145753.13080-1-hanguidong02@gmail.com> In-Reply-To: On Tue Jan 13, 2026 at 10:55 AM CET, Danilo Krummrich wrote: > On Thu Nov 27, 2025 at 3:57 PM CET, Gui-Dong Han wrote: >> diff --git a/drivers/base/base.h b/drivers/base/base.h >> index 86fa7fbb3548..72791125de91 100644 >> --- a/drivers/base/base.h >> +++ b/drivers/base/base.h >> @@ -166,6 +166,9 @@ void device_set_deferred_probe_reason(const struct d= evice *dev, struct va_format >> static inline int driver_match_device(const struct device_driver *drv, >> struct device *dev) >> { >> + /* Protects against driver_set_override() races */ >> + device_lock_assert(dev); >> + >> return drv->bus->match ? drv->bus->match(dev, drv) : 1; >> } > > I am not convinced that this is the correct fix, since > > 1. Not all match() callbacks access the driver_override field, > > 2. driver_override is accessed in other places as well, > > 3. driver_override is a bus device specific field (with a common > helper admittedly). > > I think it would be better to make driver_override a field in the base > struct device. This way we can not only provide driver_set_override(), bu= t also > driver_get_override(), which should contain the device_lock_assert() inst= ead. We should probably avoid the term 'get' in the accessor, since it could be misleading. More generally the naming is a bit odd: driver_set_override() reads as if w= e'd set an override field of some driver structure, whereas we actually set the driver_override field of a device structure. Hence, I'd suggest to eventually go with dev_set_driver_override() and dev_access_driver_override() (or just dev_driver_override()). Also, the documentation of the accessor should document that the returned pointer is only valid as long as the lock is held. (In Rust it would be possible to make the compiler ensure that the returned pointer can't be accessed anymore after the lock is dropped.) > While not all devices require the driver_override field, an additional po= inter > in struct device does not hurt and it clarifies ownership and hence locki= ng. > > - Danilo