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 83B3327B34D for ; Tue, 13 Jan 2026 14:20:08 +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=1768314008; cv=none; b=BYPB1GNfNHAp0A/j+J49ZE/jpm5LGKEyl30EGXzcS2nixVKAGao2Yf6zEavVZlYhEiCPO6rZ3pw0kIO3FD9NK8F0LwYP/In7ZO81CBghXlpSWJ+iZmNmtbo0VMTUDzy2SBCAJ49FHjmJzvKI08Aef/bZobgniGtEjv21Li/+YeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768314008; c=relaxed/simple; bh=vSveYgfmKbiHV+F2+XDWCNEUx1Tfu9zyavj+nCPEKL4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=h5I7IOrCklBqLVOgfzbcn5IoG0RXrj+AKDMmrAkhXEa7A30pjwrGDFmpWV0dghg/wEkfQw6Lbq5qBwDcfbZGCmVZVy8qObkHvPDjsBL1ttcSyxntdvTbNgTPU6JHI99BOc9Rx0fLAlpkFj+nA3iRBsZ35JH7P9qKcaQ8N8fzia8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YeNzwoTw; 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="YeNzwoTw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1A51C116C6; Tue, 13 Jan 2026 14:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768314008; bh=vSveYgfmKbiHV+F2+XDWCNEUx1Tfu9zyavj+nCPEKL4=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=YeNzwoTwSygcoP6etTyQ+iUtMRSlCDSWleP5DhNJpJasSyjBMmnGPhRoejDsmuecC xffzd0llEI+uIvc+hTLB2sVKJuaA2DnDFKaa7ZiSBJsvZugWWbNa/KbtGGVJhIXID5 cf4Axgt0h9HPisVA9gqrKKFoQDkCmkxkb3g8IN8bNLzBcCE+PHcWHJ45xRmJz9EAN6 AiUG8RQR5PoO9yfXqaZsEXX+s6qo8QSkZ+0+HDIJnLZu7l/zYjmxvHtKJQtdOsEacP npkT23OgecCc0zeygsAYdZyj2wBqB6x4hbUggGIPPQcNt74NMjd6YcBDZW+dYLabhm yek8dYomzTF1w== 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 15:20:04 +0100 Message-Id: Cc: , , , , "Qiu-ji Chen" , <2045gemini@gmail.com> To: "Gui-Dong Han" From: "Danilo Krummrich" Subject: Re: [PATCH v3] driver core: fix use-after-free of driver_override via driver_match_device() References: <20251127145753.13080-1-hanguidong02@gmail.com> In-Reply-To: On Tue Jan 13, 2026 at 3:05 PM CET, Gui-Dong Han wrote: > I see your point now. I agree that we should frame this as fixing the > inconsistent locking guarantee of match() callbacks. This is exactly > what the code changes in my patch implement. The fix for > driver_override UAF is a natural result of this consistency. > > I plan to send a v4 to update the subject and commit log to focus on > enforcing consistent locking. Great, thanks! > For the code comment, I will remove the mention of > driver_set_override. Do you prefer /* Ensure consistent locking for > match() callbacks */ or simply no comment? I think both is fine, the comment probably doesn't hurt. > Regarding the larger refactoring of driver_override, I am willing to > look into it as a follow-up task. Thanks!