From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 96A333FDBF7; Tue, 22 Sep 2026 21:24:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790112298; cv=none; b=E6vpIj1p+jGIe8miVpFgaXb3fTmBc6RGaXSjMxOCRQzOgj92FAaQ9VNr7mxyVJkEc7puahRflHXLpXPltUy65En9GVd2IgbCGPanvjBzePxXr+kOeljtvLgICwlTu3xFux0A9cYR3Zh+H93oRPKsZyLEfq4cXzPV6BRiO5usVks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790112298; c=relaxed/simple; bh=YdbB4HHFr5RiQMEKS7IZDCgTEt//MSoaU0ovnWKgFaY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=t5rnEKhk/yrAiv9pTCG5FUQeA9JvZSzMrggoqvUvYmWFDSLTwiulrUOuI5mA/oly8ZDeHwF2tx+xGDpmxIXm4//ioJSqjm2N0jLe3/ANt52TgpU4Qx7PVtNYsmtsvtw9T39ZeIzvZagymgrT4hzLr6WVFVBRE34DjgoTvtaNK90= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=o5zlNzoT; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="o5zlNzoT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1790112277; bh=YdbB4HHFr5RiQMEKS7IZDCgTEt//MSoaU0ovnWKgFaY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=o5zlNzoTZhj10MvLCN9RERRNk12QLtK1kfvAIFY9TWvY/x0Vx7xXCU4Qz27NEc4Ao j/ScP5/FJpyAOQuM47UzkcQnjLTVwkbYLodGxtqPQ7VTjmpUvi/L3VDRLToQiAjhfm VweugPVCerh94lN8/qmLvIRTKDymIrI+NIQL+s738bw7ANjnj9lSQ1qKJHwwrlXJl/ z01fNYmGCkIVtIHgICRqShsBygE0Y7GXKbVYsy59CEygo3B1nk1KZfm6s2feoq9fAi oKFau036K6gwAaZWkMVz62G1H+DjbV2h3FkOE7erBDjSnwEPf/bNIG03yhO+LqGzrU 6sp7bDQ5Lgqhg== Received: from [100.64.0.241] (unknown [100.64.0.241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id B185817E006F; Tue, 22 Sep 2026 23:24:30 +0200 (CEST) Message-ID: <743283af-753a-40bb-96f3-d05b1e38e186@collabora.com> Date: Wed, 23 Sep 2026 00:24:28 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 13/74] drm/bridge: Fix NULL deref in drm_bridge_add() for legacy bridges To: Luca Ceresoli , Maxime Ripard Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Dave Stevenson , Dmitry Baryshkov , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Chen-Yu Tsai , Samuel Holland , =?UTF-8?Q?Ma=C3=ADra_Canal?= , Raspberry Pi Kernel Maintenance , Raphael Gallais-Pou , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Algea Cao , Daniel Stone , Liu Ying , Phong LE , Helge Deller , kernel@collabora.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-rockchip@lists.infradead.org, linux-fbdev@vger.kernel.org, Sashiko References: <20260901-dw-hdmi-qp-scramb-v11-0-bc12954a0688@collabora.com> <20260901-dw-hdmi-qp-scramb-v11-13-bc12954a0688@collabora.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Luca, On 9/21/26 10:05 AM, Luca Ceresoli wrote: > On Tue Sep 8, 2026 at 11:24 AM CEST, Maxime Ripard wrote: >> On Tue, Sep 01, 2026 at 09:50:37PM +0300, Cristian Ciocaltea wrote: >>> Legacy bridge drivers that embed struct drm_bridge in a zero-initialized >>> allocation, rather than obtaining it from devm_drm_bridge_alloc(), never >>> run INIT_LIST_HEAD() on bridge->list, leaving next and prev NULL. >>> list_empty() compares next against &bridge->list, so it reports such a >>> list head as non-empty. list_del_init() therefore runs and dereferences >>> the NULL pointers, panicking the kernel during probe. Only builds with >>> CONFIG_DEBUG_LIST survive, with a list corruption report. >>> >>> This affects rk3066_hdmi and the i.MX8 LDB bridges, which still embed a >>> bridge in a devm_kzalloc()'d struct. >>> >>> Initialize the list head when it is found to be NULL, so that the bridge >>> ends up with a valid empty list head and list_del_init() is only reached >>> for bridges that can actually be linked. >>> >>> Fixes: 17805a15d175 ("drm/bridge: add list of removed refcounted bridges") >>> Reported-by: Sashiko >>> Closes: https://lore.kernel.org/all/20260731175016.C5D591F00AC4@smtp.kernel.org/ >>> Signed-off-by: Cristian Ciocaltea >>> --- >>> drivers/gpu/drm/drm_bridge.c | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c >>> index 2c457ad74f3b..a8b6df5c13ea 100644 >>> --- a/drivers/gpu/drm/drm_bridge.c >>> +++ b/drivers/gpu/drm/drm_bridge.c >>> @@ -453,9 +453,16 @@ void drm_bridge_add(struct drm_bridge *bridge) >>> * If the bridge was previously added and then removed, it is now >>> * in bridge_lingering_list. Remove it or bridge_lingering_list will be >>> * corrupted when adding this bridge to bridge_list below. >>> + * >>> + * Legacy drivers that allocate the bridge with kzalloc() rather than >>> + * devm_drm_bridge_alloc() leave list.next NULL. Such a bridge cannot >>> + * be on any list, and list_del_init() would dereference NULL, so >>> + * initialize the list head first. >> >> "legacy" bridges are ambigous and was also used for non-atomic bridges. >> That being said, it's now *required* that bridges use >> devm_drm_bridge_alloc() instead of kzalloc, and we warn in >> drm_bridge_add if it hasn't. >> >> So I don't think we should merge this patch. > > I agree. > > I theory all drivers are be already using devm_drm_bridge_alloc() by now. > > In practice rk3066_hdmi is actually still using kzalloc, it should be fixed > to use devm_drm_bridge_alloc(). Are you OK with doing it in v12? Yes, I'll send this a separate series, together with the other bridge fixes. > By "i.MX8 LDB" I guess you mean fsl-ldb.c, which was converted in > 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to > devm_drm_bridge_alloc() API"). I was actually referring to imx8q*-ldb.c, but it turns out those were converted as well - I incorrectly flagged them because the probe functions still contain imx8qm_ldb = devm_kzalloc(dev, sizeof(*imx8qm_ldb), GFP_KERNEL); I've just realized the struct drm_bridge is not embedded in struct imx8qm_ldb,but it's part of struct ldb_channel. Sorry for the confusion. Thanks for the reviews & tests! Regards, Cristian