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 DE07C19B5B1 for ; Thu, 23 Apr 2026 10:18:36 +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=1776939516; cv=none; b=CQBY6iq/kgQ8AGx0WNV1dEjKYjwl3zPAqS8KihHwjMkH4kh7iuMliQ3L/yLTPxwTKGCXmLju9el8ESudeUjga/xVoerHv/guH4OAUwBaOhxOhK1pq3r/B0rlNqKA3SpfFlnSNIUn9gW0baR5SkL6TqQ1pAs4HCb2uiiu2o8tMz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776939516; c=relaxed/simple; bh=ZXq2fGzF3baRtOkzR6/UWZvmPhl8qyFGt/u1hfLtn/Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=BwH7QBQBnyaH4OstLPk6t68XPrLe4NBBgt+0VGlbbFP1/Mok5iuQ4xfTzOsQTHungKv0A2TvWR/xl9zx/liAcU16pdTfTARPYhTJsPE2arJAISRq5nMcCQZ7OH+Zih4zYjwHAmjpgjmxmcWUwriiDS8iBgh81dF6fY6Rh5fd2uc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ICxR71xu; 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="ICxR71xu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 256B1C2BCB2; Thu, 23 Apr 2026 10:18:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776939516; bh=ZXq2fGzF3baRtOkzR6/UWZvmPhl8qyFGt/u1hfLtn/Y=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ICxR71xuSXF0nNaggipC4agYg8UZsT/28BjdRSYaaAIYl6mcHaZ7e2nUmuTPgX7oq V+9xmb9AY3/3mKGRB1S8rP2Ph4RRbC03n+6ET0aEmwGTy5EbSG/DYE44b1STNhlLMc S7KYWN3DHlc6NZr7xOmoHz/K3xbqUrBRpd+PI063RJn/CPkKN4w066N8qSBjm5s0q5 6dGZwhSAoliia6L0YdpWUKFcZZ8BJlkynYR7mCnjCCp/96RYVe9ls5uYr8PjrlSgXA 2uiFHomduVNfYjSX0D7zqgDgjYfYYQyFHR3hCXoGwFbjO4pqWWRoGY8vQWhz67fZkr T0lj6mDfSkoqw== From: Maxime Ripard Date: Thu, 23 Apr 2026 12:18:15 +0200 Subject: [PATCH v2 02/28] drm/atomic_helper: Skip over NULL private_obj pointers Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260423-drm-state-readout-v2-2-8549f87cb978@kernel.org> References: <20260423-drm-state-readout-v2-0-8549f87cb978@kernel.org> In-Reply-To: <20260423-drm-state-readout-v2-0-8549f87cb978@kernel.org> To: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Jyri Sarha , Tomi Valkeinen Cc: Devarsh Thakkar , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2100; i=mripard@kernel.org; h=from:subject:message-id; bh=ZXq2fGzF3baRtOkzR6/UWZvmPhl8qyFGt/u1hfLtn/Y=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDJkvP76ImMfhKxey9+v/20eaX37c0hTlknWdf90jj+Yb0 2s2zdwU2jGVhUGYk0FWTJHliUzY6eXti6sc7Ff+gJnDygQyhIGLUwAmEnWUsVbG+MSB04wqHA+O S7t2TkmY/snkklzV8zLfZvOAMNtQ/b59lv373zwxv/Yt2i38VWWnJmPDmodz3xjmpV488arZK2n vRAeex23vD5Wd2OZuNO+lKEf6vRBZjsqlXpOi+rjnvO0UX3AfAA== X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D Just like for connectors, drm_atomic_state contains an array of drm_private_state, with the number of states found in num_private_objs. If we are to clean up a state by hand for some reason before calling drm_atomic_state_put(), chances are that the pointer to the affected drm_private_obj and drm_private_states would have been cleared to avoid any use-after-free. However, since it's just an array, as we progress and free the items, we can't update num_private_objs as we go since we would reduce the array size, preventing us to remove the final elements. And if the caller was to forget to update num_private_objs after it iterated over the whole array, we're left with a (valid) array with a non-zero number of NULL elements. If we were to call drm_atomic_state_put() at this point, chances are that drm_atomic_state_default_clear() would be called and it would iterate over all those empty NULL items. However, unlike what is found for connectors, crtcs and planes, we don't test that our pointers are non-NULL before dereferencing them, leading to a NULL pointer dereference. Such callers should obviously be fixed, but there's no reason to not do such a simple check, if only to be consistent. Reviewed-by: Thomas Zimmermann Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 3bd52602fe30..84bc91886b4c 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -334,10 +334,13 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state) } for (i = 0; i < state->num_private_objs; i++) { struct drm_private_obj *obj = state->private_objs[i].ptr; + if (!obj) + continue; + obj->funcs->atomic_destroy_state(obj, state->private_objs[i].state_to_destroy); state->private_objs[i].ptr = NULL; state->private_objs[i].state_to_destroy = NULL; state->private_objs[i].old_state = NULL; -- 2.53.0