From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 D0D83370D7B for ; Sun, 5 Jul 2026 23:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783294734; cv=none; b=YByTVIVbB0rqvtTXVDxJSnpUCjCRN2Knzv15osTWhpyhaskBHllnwXrtOs4IlZR/RUt4LCgtq+qa3+F43JNE4X5jcvLPQAO/aTU7iTjfQYsuYVdxz9mv+Z90+r9KKVwoNGoultxuIGlKgQulQeTdfCkOHYC5BvWQo0fHU423+pM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783294734; c=relaxed/simple; bh=CKr70Bl7SDnv+itCSOhLjyRNH9/JCWI6hs/gsrk/9BY=; h=Message-ID:From:To:Cc:Subject:Date:In-Reply-To:References: Content-Type:MIME-Version; b=avUYY/DxTZmsS3okjSvKZwbfeM59CZjyk+T6nqdPKgHKigxf+Omcw5iUlWnyR0uLbRoNnMUwyzsec9RzIIwXq8lnPFwNPwZN6TsYMks/SA51yAwTKMEMem0ZZbxlSD6dxtAAvMRQVnXa6pMJGn/kO6O+xKHfv7IRWs1cB8fJyUI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=X+nTM1Up; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="X+nTM1Up" Received: from killaraus.ideasonboard.com (2001-14ba-70f3-e800--a06.rev.dnainternet.fi [IPv6:2001:14ba:70f3:e800::a06]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 98FA2741; Mon, 6 Jul 2026 01:38:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1783294683; bh=CKr70Bl7SDnv+itCSOhLjyRNH9/JCWI6hs/gsrk/9BY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X+nTM1UpQGaDjCCbrKs8a926nKNRXlYJu4kGjmk0blxy95UwK+eDTDWd+PkdzvCQh dSHgpjB+bUEcjTOaoKvZUARoiv3ku1BiZwqJzi1oKhuMZODrGTJZQ0SckKGBnDtuZS GEOZIOXk5rvt+tNieFvB+91Ra+vsz/rkaGK950xM= Message-ID: <1ad604017b0d28663842a86aa036340b@killaraus.ideasonboard.com> From: Laurent Pinchart To: sashiko-reviews@lists.linux.dev Cc: robh@kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, conor+dt@kernel.org, wsa+renesas@sang-engineering.com Subject: Re: [PATCH 3/4] drm/bridge: display-connector: Support hardcoded EDID for VGA connectors Date: Mon, 06 Jul 2026 02:38:49 +0300 In-Reply-To: <20260705214453.5195C1F000E9@smtp.kernel.org> References: <20260705213542.28987-1-laurent.pinchart+renesas@ideasonboard.com> <20260705213542.28987-4-laurent.pinchart+renesas@ideasonboard.com> <20260705214453.5195C1F000E9@smtp.kernel.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hello, This is the friendly mail bot of Laurent Pinchart. You have sent him what appears to be an e-mail generated by an LLM. In order to preserve his mental health, the e-mail has been automatically ignored. Thank you, Laurent's spam bot On Sun, 05 Jul 2026 21:44:52 +0000, sashiko-bot@kernel.org wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: >=20 > Pre-existing issues: > - [High] Use-After-Free of devm-managed resources and missing asynchronous = cleanup during device removal when the driver is unbound. > -- >=20 > commit 48f63e147d7554f73cd9df360e29fd0b0ddb5d8d > Author: Laurent Pinchart >=20 > drm/bridge: display-connector: Support hardcoded EDID for VGA connectors >=20 > This commit adds support for parsing a hardcoded EDID blob from the device = tree > for VGA connectors when DDC signals are not connected. It also ensures that > specifying both a DDC bus and a hardcoded EDID returns an error during prob= e. >=20 > > diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm= /bridge/display-connector.c > > index eb3412ec30a07..225a8e987d086 100644 > > --- a/drivers/gpu/drm/bridge/display-connector.c > > +++ b/drivers/gpu/drm/bridge/display-connector.c >=20 > [ ... ] >=20 > > @@ -64,6 +67,9 @@ static enum drm_connector_status display_connector_dete= ct(struct drm_bridge *bri > > if (conn->bridge.ddc && drm_probe_ddc(conn->bridge.ddc)) > > return connector_status_connected; > > =20 > > + if (conn->edid) > > + return connector_status_connected; > > + >=20 > [Severity: High] > This isn't a bug introduced by this patch, but does device removal have a > use-after-free vulnerability when the driver is unbound via sysfs? >=20 > Looking at display_connector_detect() in=20 > drivers/gpu/drm/bridge/display-connector.c, if the driver is bound and atta= ched > to a DRM encoder, and then unbound via sysfs: >=20 > 1. display_connector_remove() calls drm_bridge_remove() but does not call > disable_irq() or cancel_work_sync(&conn->hpd_work). > 2. The bridge structure is kept alive because the DRM core still holds a > reference count. > 3. The driver core's devres_release_all() runs and frees conn->hpd_gpio and > the IRQ. >=20 > If the DRM core then polls detect, it will execute display_connector_detect= (): >=20 > if (conn->hpd_gpio) { > if (gpiod_get_value_cansleep(conn->hpd_gpio)) > ... >=20 > Will this dereference the devres-freed conn->hpd_gpio? >=20 > Additionally, if the concurrent hpd_work executes, will it attempt to lock > bridge->hpd_mutex which was already destroyed by drm_bridge_remove()? >=20 > > switch (conn->bridge.type) { > > case DRM_MODE_CONNECTOR_DVIA: >=20 > [ ... ] >=20