linux-kernel - [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20250116111636.157641-1-j-choudhary@ti.com>
Date: Thu, 16 Jan 2025 16:46:36 +0530
From: Jayesh Choudhary <j-choudhary@...com>
To: <dri-devel@...ts.freedesktop.org>, <sjakhade@...ence.com>, <jsarha@...com>,
        <tomi.valkeinen@...asonboard.com>, <mripard@...nel.org>,
        <Laurent.pinchart@...asonboard.com>, <andrzej.hajda@...el.com>,
        <neil.armstrong@...aro.org>, <rfoss@...nel.org>
CC: <amishin@...rgos.ru>, <jani.nikula@...el.com>, <tzimmermann@...e.de>,
        <maarten.lankhorst@...ux.intel.com>, <jonas@...boo.se>,
        <jernej.skrabec@...il.com>, <linux-kernel@...r.kernel.org>,
        <devarsht@...com>, <j-choudhary@...com>
Subject: [RFC PATCH] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference

For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
the connector structure is not initialised in the bridge. That's done
by encoder. So in case of some failure in cdns_mhdp_atomic_enable,
when we schedule work for modeset_retry_work, we will use the mutex
of connector which will result in NULL pointer dereference.
Handle it by adding condition for the connector. Otherwise, since
the modeset_retry_work tries to set the connector status as bad,
set the mhdp->plugged as false which would give the connector
status as disconnected in detect hook.

Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
Signed-off-by: Jayesh Choudhary <j-choudhary@...com>
---

NOTE: Found this issue in one particular board where edid read failed.
Issue log: <https://gist.github.com/Jayesh2000/233f87f9becdf1e66f1da6fd53f77429>

Adding conditional fixes the null pointer issue but there is still
flooding of these logs (128 times):
"cdns-mhdp8546 a000000.bridge: Failed to read DPCD addr 0"

Sending RFC as I am still not sure about how to handle this flooding.
Is it okay to decrease the log level for DPCD read and DPCD write in
the cdns_mhdp_transfer to debug?

 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 24 ++++++++++---------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d081850e3c03..6a121a2700d2 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2363,18 +2363,20 @@ static void cdns_mhdp_modeset_retry_fn(struct work_struct *work)
 
 	mhdp = container_of(work, typeof(*mhdp), modeset_retry_work);
 
-	conn = &mhdp->connector;
-
-	/* Grab the locks before changing connector property */
-	mutex_lock(&conn->dev->mode_config.mutex);
-
-	/*
-	 * Set connector link status to BAD and send a Uevent to notify
-	 * userspace to do a modeset.
-	 */
-	drm_connector_set_link_status_property(conn, DRM_MODE_LINK_STATUS_BAD);
-	mutex_unlock(&conn->dev->mode_config.mutex);
+	if (mhdp->connector.dev) {
+		conn = &mhdp->connector;
+		/* Grab the locks before changing connector property */
+		mutex_lock(&conn->dev->mode_config.mutex);
 
+		/*
+		 * Set connector link status to BAD and send a Uevent to notify
+		 * userspace to do a modeset.
+		 */
+		drm_connector_set_link_status_property(conn, DRM_MODE_LINK_STATUS_BAD);
+		mutex_unlock(&conn->dev->mode_config.mutex);
+	} else {
+		mhdp->plugged = false;
+	}
 	/* Send Hotplug uevent so userspace can reprobe */
 	drm_kms_helper_hotplug_event(mhdp->bridge.dev);
 }
-- 
2.34.1