From: sashiko-bot@kernel.org
To: "Satyajit Roy" <edu042sjroy@proton.me>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output
Date: Sun, 30 Aug 2026 04:06:33 +0000 [thread overview]
Message-ID: <20260830040634.3E9B01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830035120.937992-3-edu042sjroy@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] NULL pointer dereference in `amdgpu_dm_atomic_commit_tail` when changing the `Broadcast RGB` connector property.
--
commit 25a82016e5e929302d7c5fe7edf379f4e6cec7a0
Author: Satyajit Roy <sroy14@alum.utk.edu>
drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output
This patch updates amdgpu_dm_get_output_color_space() to apply the Broadcast
RGB connector property for BT.2020 RGB output. It explicitly selects limited
range when requested, fixing an issue where it always defaulted to full range.
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_connector.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_connector.c
> index 8a35e4df13cbf..f2f6a2a0db99e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_connector.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_connector.c
> @@ -758,10 +758,14 @@ amdgpu_dm_get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
> break;
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> - if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB)
> - color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> - else
> + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
> + if (connector_state->hdmi.broadcast_rgb == DRM_HDMI_BROADCAST_RGB_LIMITED)
> + color_space = COLOR_SPACE_2020_RGB_LIMITEDRANGE;
> + else
> + color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> + } else {
> color_space = COLOR_SPACE_2020_YCBCR_LIMITED;
> + }
> break;
> case DRM_MODE_COLORIMETRY_DEFAULT: /* ITU601 */
[Severity: Critical]
This is a pre-existing issue, but does changing the Broadcast RGB property
crash the kernel via a NULL pointer dereference?
When userspace changes the Broadcast RGB property on a connector, DRM core
creates an atomic commit containing only the updated connector state. The AMD
driver's amdgpu_dm_atomic_check() does not add the associated CRTC to the
atomic state for these broadcast_rgb changes.
This leads to a crash in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
within amdgpu_dm_atomic_commit_tail(), where drm_atomic_get_new_crtc_state()
returns NULL:
if (acrtc) {
new_crtc_state = drm_atomic_get_new_crtc_state(state, &acrtc->base);
old_crtc_state = drm_atomic_get_old_crtc_state(state, &acrtc->base);
}
/* Skip any modesets/resets */
if (!acrtc || drm_atomic_crtc_needs_modeset(new_crtc_state))
continue;
Since new_crtc_state is NULL, drm_atomic_crtc_needs_modeset() unconditionally
dereferences it and crashes.
Even if this did not crash (for example on a disabled CRTC where modeset
might evaluate to false), execution proceeds to the fast-update path in
the same function:
if ((new_con_state->hdmi.broadcast_rgb != old_con_state->hdmi.broadcast_rgb) &&
(dm_old_crtc_state->stream->output_color_space !=
amdgpu_dm_get_output_color_space(&dm_new_crtc_state->stream->timing, new_con_state)))
For a disabled CRTC, stream is NULL, which causes dm_new_crtc_state->stream
and dm_old_crtc_state->stream to trigger a second unavoidable NULL pointer
dereference.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830035120.937992-1-edu042sjroy@proton.me?part=2
next prev parent reply other threads:[~2026-08-30 4:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 3:51 [PATCH 0/3] drm/amd/display: Fix HDMI RGB quantization updates Satyajit Roy
2026-08-30 3:51 ` [PATCH 1/3] drm/amd/display: Propagate HDMI RGB quantization selectability Satyajit Roy
2026-08-30 3:52 ` [PATCH 2/3] drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output Satyajit Roy
2026-08-30 4:06 ` sashiko-bot [this message]
2026-08-30 14:37 ` edu042sjroy
2026-08-30 3:52 ` [PATCH 3/3] drm/amd/display: Rebuild InfoFrames on output color space changes Satyajit Roy
2026-09-08 19:36 ` [PATCH 0/3] drm/amd/display: Fix HDMI RGB quantization updates Alex Hung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830040634.3E9B01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=edu042sjroy@proton.me \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.