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 C63A737882B for ; Thu, 23 Apr 2026 10:07:24 +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=1776938844; cv=none; b=G3IQuTvD7JasbucTBuVw48Wdi1mrcWNNgmHq31oq3PBRBtuuaq9SFDuekazieLQvWpiYcfYQ+1V2KohoeAF2qbkdp88lzP/tl+JNVO/Ckr132Tr3Ejywt/kxPc19LfRiY059yDiM4/1pslnB4ZTcw53b8gtE9B4TaW2RbYp4cvs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776938844; 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=dbbhE1oqel+HO6SxbfcccGEcnxDYkGASDiFNt+Ac6zEJqR3JUI5lh9J6Ce7oFVzSNLVgZkF6WZd5MWVioNIicFM8FK2ZuocO/KgllA295jn4CTsawduFvqRfcSNam/095lhWbJBduoE+KWd4V2FAk7ki1xtejYp9rYGIDp2Atks= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GzwbDIGR; 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="GzwbDIGR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3658FC2BCAF; Thu, 23 Apr 2026 10:07:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776938844; bh=ZXq2fGzF3baRtOkzR6/UWZvmPhl8qyFGt/u1hfLtn/Y=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=GzwbDIGR+/46zMPO/yggfY1RrFCc+IiungeeLDyA/tXSLWweIO5oVVr5mnM0a5EbK zP7nH6l7VmW1rH9dqjGIoQ6IF6+34THoG/LKHRSBrKBBUsOo10bf3Mx2TWy6QbdjKj SnxwoI0JTTl4yVffbde/Ntz5xrSG5n8YbnNfFUWIu/gr7Vt2IaH0ePxQUhy8KpR9bI HuLTWUwIs7oNucKYZa1YWLwU/ZMEwko9JAfMi31wRcWYF1C/b0DqptZnbXLDQeAhYZ AMLYoRal/afgCnHfEdOiQGqZQztYIkE4eUn03TFWUEOmwrCWpXfTFrK4SbIHs1rcvj E+oH+8hv3cVJg== From: Maxime Ripard Date: Thu, 23 Apr 2026 12:06:40 +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-6cde1a9910ed@kernel.org> References: <20260423-drm-state-readout-v2-0-6cde1a9910ed@kernel.org> In-Reply-To: <20260423-drm-state-readout-v2-0-6cde1a9910ed@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=owGbwMvMwCmsHn9OcpHtvjLG02pJDJkv37tnS7ArfL+UpLgrbfZ0xfcPsybeMjC0uvozZmlY1 vY3b7dldkxlYRDmZJAVU2R5IhN2enn74ioH+5U/YOawMoEMYeDiFICJXL/HWKda6S8Vp785tshk OtOkv27Mkw4fOfJ4p+0sy5A5nxZ3eVafzPK7Khhavc51otUuh+IZYYz1XttXL9uSpcbopPRXc0G PygN16enz/FZwaIfNFSxbEL2hrubD0qUu6ntmiaplL1d8+sUCAA== 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