From: sashiko-bot@kernel.org
To: "Alexey Velichayshiy" <a.velichayshiy@ispras.ru>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/radeon: Add NULL pointer check for enc_priv in atombios_set_encoder_crtc_source()
Date: Sat, 20 Jun 2026 18:50:47 +0000 [thread overview]
Message-ID: <20260620185048.4EF421F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260620183150.1248791-1-a.velichayshiy@ispras.ru>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete fix for NULL pointer dereference. The patch adds a local check for `enc_priv` (`dig`) in `atombios_set_encoder_crtc_source()`, but leaves the root cause unaddressed. In `radeon_add_atom_encoder()`, if the memory allocation for `enc_priv` fails (e.g., via `radeon_atombios_get_lvds_info()`, `radeon_atombios_set_dig_info()`, or `radeon_atombios_set_dac_info()`), the error is ignored and the encoder is registered with a NULL `enc_priv`. This broken encoder is then passed to numerous other functions (like `atombios_dig_encoder_setup2`, `atombios_dig_transmitter_setup2`, and `atombios_dac_setup`) which unconditionally dereference `enc_priv` (via `dig` or `dac_info`), leading to guaranteed kernel panics. The proper fix is to handle the allocation failure at the source and abort encoder registration.
- [High] The driver automatically defaults the display scaling mode to RMX_FULL for LCD devices, which violates the DRM subsystem guideline on scaling modes. This stretches the image and distorts its aspect ratio (e.g., circles become ovals) instead of preserving it.
--
commit 21561a0f42099aab9f6cd586dc86a1e791580aef
Author: Alexey Velichayshiy <a.velichayshiy@ispras.ru>
drm/radeon: Add NULL pointer check for enc_priv in atombios_set_encoder_crtc_source()
This commit adds a NULL pointer check for enc_priv in
atombios_set_encoder_crtc_source() to prevent a NULL pointer dereference.
The issue was reported to be found with SVACE.
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 3d9f47bc807af..6efb6bd2d344c 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
[ ... ]
> @@ -1931,6 +1931,8 @@ atombios_set_encoder_crtc_source(struct drm_encoder *encoder)
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
> case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
> dig = radeon_encoder->enc_priv;
> + if (!dig)
> + return;
[Severity: High]
This isn't a bug introduced by this patch, but does this local check leave
the root cause unaddressed?
In drivers/gpu/drm/radeon/atombios_encoders.c:radeon_add_atom_encoder(), if
the memory allocation for enc_priv fails (e.g. via
radeon_atombios_set_dig_info()), the error is ignored and the encoder is
registered with a NULL enc_priv:
radeon_add_atom_encoder() {
...
radeon_encoder->enc_priv = radeon_atombios_set_dig_info(radeon_encoder);
...
}
This broken encoder is then passed to numerous other functions which
unconditionally dereference enc_priv, such as:
atombios_dig_encoder_setup2() {
...
if (dig->dig_encoder == -1)
...
}
atombios_dig_transmitter_setup2() {
...
int dig_encoder = dig->dig_encoder;
...
}
atombios_dac_setup() {
...
switch (dac_info->tv_std) {
...
}
Since other DRM callbacks will unconditionally dereference it, could we handle
the allocation failure at the source and abort encoder registration instead?
[Severity: High]
This is a pre-existing issue, but does this driver incorrectly default to
distorting the aspect ratio for LCD devices?
Also in drivers/gpu/drm/radeon/atombios_encoders.c:radeon_add_atom_encoder():
radeon_add_atom_encoder() {
...
radeon_encoder->rmx_type = RMX_FULL;
...
}
Setting the default scaling mode to RMX_FULL stretches the image and
distorts its aspect ratio (e.g., circles become ovals). Should this
default to RMX_ASPECT instead to preserve the aspect ratio?
> switch (dig->dig_encoder) {
> case 0:
> args.v2.ucEncoderID = ASIC_INT_DIG1_ENCODER_ID;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620183150.1248791-1-a.velichayshiy@ispras.ru?part=1
parent reply other threads:[~2026-06-20 18:50 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260620183150.1248791-1-a.velichayshiy@ispras.ru>]
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=20260620185048.4EF421F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=a.velichayshiy@ispras.ru \
--cc=dri-devel@lists.freedesktop.org \
--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.