All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size
@ 2026-09-14 13:29 Hari Mishal
  2026-09-14 13:55 ` sashiko-bot
  2026-09-14 16:00 ` Alex Deucher
  0 siblings, 2 replies; 3+ messages in thread
From: Hari Mishal @ 2026-09-14 13:29 UTC (permalink / raw)
  To: Kenneth Feng
  Cc: Alex Deucher, Christian König, David Airlie, Simona Vetter,
	Hawking Zhang, Xiang Liu, Lijo Lazar, Yang Wang, Asad Kamal,
	Rex Zhu, amd-gfx, dri-devel, linux-kernel, Greg Kroah-Hartman,
	Hari Mishal

atomctrl_get_smc_sclk_range_table() copies ucSclkEntryNum entries from
the VBIOS SMU_Info table into pp_atom_ctrl_sclk_range_table. Both the
source (asSclkFcwRangeEntry[]) and destination (table->entry[]) arrays
are fixed at MAX_SCLK_RANGE (8) entries, but ucSclkEntryNum is an
unchecked u8 read straight from the VBIOS, so it can be up to 255. The
destination is stack-allocated in both callers
(polaris10_get_sclk_range_table(), vegam_get_sclk_range_table()), so a
count above 8 overflows a stack buffer, not just a heap read.

Reject counts above MAX_SCLK_RANGE rather than clamping to it. Only
one version of this VBIOS struct (ATOM_SMU_INFO_V2_1) has ever
existed, so a count above 8 corresponds to no legitimate table format
and means either a corrupted or a tampered VBIOS.

Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.")
Assisted-by: gkh_clanker_t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
index 4b796d60b03d..3217ad3c1d17 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
@@ -1025,6 +1025,9 @@ int atomctrl_get_smc_sclk_range_table(struct pp_hwmgr *hwmgr, struct pp_atom_ctr
 	if (!psmu_info)
 		return -EINVAL;
 
+	if (psmu_info->ucSclkEntryNum > MAX_SCLK_RANGE)
+		return -EINVAL;
+
 	for (i = 0; i < psmu_info->ucSclkEntryNum; i++) {
 		table->entry[i].ucVco_setting = psmu_info->asSclkFcwRangeEntry[i].ucVco_setting;
 		table->entry[i].ucPostdiv = psmu_info->asSclkFcwRangeEntry[i].ucPostdiv;
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size
  2026-09-14 13:29 [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size Hari Mishal
@ 2026-09-14 13:55 ` sashiko-bot
  2026-09-14 16:00 ` Alex Deucher
  1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-09-14 13:55 UTC (permalink / raw)
  To: Hari Mishal; +Cc: dri-devel

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Unvalidated VBIOS array sizes and offsets cause out-of-bounds memory reads in atomctrl_get_leakage_vddc_base_on_leakage().
- [High] Missing VBIOS table size check in `atomctrl_get_avfs_information` allows out-of-bounds memory reads.
- [Medium] Fallback path uses uninitialized `smu_data->range_table` if the VBIOS table was successfully loaded.
- [Medium] The function `get_edc_leakage_table` correctly calculates the offset but incorrectly returns a pointer to the base table.
--

commit 79900a4165725430ba1e1ef41665d1982912cab7
Author: Hari Mishal <harimishal1@gmail.com>

drm/amd/pm: bound SCLK FCW range entries to the table size

This patch limits the number of entries read from the VBIOS SMU_Info table
into pp_atom_ctrl_sclk_range_table to MAX_SCLK_RANGE. It prevents a stack
buffer overflow caused by an unchecked ucSclkEntryNum count from the VBIOS.

> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> index 4b796d60b03d4..3217ad3c1d17e 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> @@ -1025,6 +1025,9 @@ int atomctrl_get_smc_sclk_range_table(struct pp_hwmgr *hwmgr, struct pp_atom_ctr
>  	if (!psmu_info)
>  		return -EINVAL;
>  
> +	if (psmu_info->ucSclkEntryNum > MAX_SCLK_RANGE)
> +		return -EINVAL;
> +
>  	for (i = 0; i < psmu_info->ucSclkEntryNum; i++) {
>  		table->entry[i].ucVco_setting = psmu_info->asSclkFcwRangeEntry[i].ucVco_setting;
>  		table->entry[i].ucPostdiv = psmu_info->asSclkFcwRangeEntry[i].ucPostdiv;

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing VBIOS bounds
checking in ppatomctrl.c, I noticed another potential out-of-bounds read in
atomctrl_get_avfs_information():

drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c:atomctrl_get_avfs_information() {
	profile = (ATOM_ASIC_PROFILING_INFO_V3_6 *)
			smu_atom_get_data_table(hwmgr->adev,
					GetIndexIntoMasterTable(DATA, ASIC_ProfilingInfo),
					NULL, NULL, NULL);
	if (!profile)
		return -1;

	param->ulAVFS_meanNsigma_Acontant0 = le32_to_cpu(profile->ulAVFS_meanNsigma_Acontant0);
	...
}

Does this code fail to validate the size of the ASIC_ProfilingInfo table?

If a corrupted or older VBIOS provides a smaller table, could this lead to
reading past the end of the table mapping since the size parameter passed
to smu_atom_get_data_table() is NULL?

[Severity: High]
This is a pre-existing issue, but I found another unvalidated VBIOS array size
used in atomctrl_get_leakage_vddc_base_on_leakage():

drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c:atomctrl_get_leakage_vddc_base_on_leakage() {
	...
			for (i = 0; i < profile->ucElbVDDC_Num; i++) {
				if (vddc_id_buf[i] == virtual_voltage_id) {
	...
							*vddc = vddc_buf[j * profile->ucElbVDDC_Num + i];
	...
}

Can this loop iterate out-of-bounds if a malicious or corrupted VBIOS provides
an excessively large ucElbVDDC_Num?

The count and unvalidated offsets might lead to out-of-bounds memory reads.

[Severity: Medium]
This isn't a bug introduced by this patch, but get_edc_leakage_table() seems
to return the wrong pointer:

drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c:get_edc_leakage_table() {
	...
	temp = (char *)table_address;
	table_address += offset;

	return (AtomCtrl_EDCLeakgeTable *)temp;
}

Is this returning a pointer to the base table instead of the calculated offset?

Since table_address is incremented but temp is returned, might this cause
callers to read incorrect data from the beginning of the GFX_Info table rather
than the intended offset?

[Severity: Medium]
This is a pre-existing issue, but there seems to be an uninitialized memory
issue in the fallback path after loading the range table:

drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c:polaris10_get_sclk_range_table() {
	...
		}
		return;
	}
	...
}

drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c:polaris10_calculate_sclk_params() {
	...
		if (clock > smu_data->range_table[i].trans_lower_frequency
		&& clock <= smu_data->range_table[i].trans_upper_frequency) {
	...
}

If atomctrl_get_smc_sclk_range_table() succeeds,
polaris10_get_sclk_range_table() returns without initializing
smu_data->range_table.

If a subsequent divider calculation fails, could
polaris10_calculate_sclk_params() use this uninitialized range_table in its
fallback loop?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914132920.10127-1-harimishal1@gmail.com?part=1

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size
  2026-09-14 13:29 [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size Hari Mishal
  2026-09-14 13:55 ` sashiko-bot
@ 2026-09-14 16:00 ` Alex Deucher
  1 sibling, 0 replies; 3+ messages in thread
From: Alex Deucher @ 2026-09-14 16:00 UTC (permalink / raw)
  To: Hari Mishal
  Cc: Kenneth Feng, Alex Deucher, Christian König, David Airlie,
	Simona Vetter, Hawking Zhang, Xiang Liu, Lijo Lazar, Yang Wang,
	Asad Kamal, Rex Zhu, amd-gfx, dri-devel, linux-kernel,
	Greg Kroah-Hartman

Applied.  Thanks!

On Mon, Sep 14, 2026 at 10:36 AM Hari Mishal <harimishal1@gmail.com> wrote:
>
> atomctrl_get_smc_sclk_range_table() copies ucSclkEntryNum entries from
> the VBIOS SMU_Info table into pp_atom_ctrl_sclk_range_table. Both the
> source (asSclkFcwRangeEntry[]) and destination (table->entry[]) arrays
> are fixed at MAX_SCLK_RANGE (8) entries, but ucSclkEntryNum is an
> unchecked u8 read straight from the VBIOS, so it can be up to 255. The
> destination is stack-allocated in both callers
> (polaris10_get_sclk_range_table(), vegam_get_sclk_range_table()), so a
> count above 8 overflows a stack buffer, not just a heap read.
>
> Reject counts above MAX_SCLK_RANGE rather than clamping to it. Only
> one version of this VBIOS struct (ATOM_SMU_INFO_V2_1) has ever
> existed, so a count above 8 corresponds to no legitimate table format
> and means either a corrupted or a tampered VBIOS.
>
> Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.")
> Assisted-by: gkh_clanker_t1000
> Signed-off-by: Hari Mishal <harimishal1@gmail.com>
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> index 4b796d60b03d..3217ad3c1d17 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c
> @@ -1025,6 +1025,9 @@ int atomctrl_get_smc_sclk_range_table(struct pp_hwmgr *hwmgr, struct pp_atom_ctr
>         if (!psmu_info)
>                 return -EINVAL;
>
> +       if (psmu_info->ucSclkEntryNum > MAX_SCLK_RANGE)
> +               return -EINVAL;
> +
>         for (i = 0; i < psmu_info->ucSclkEntryNum; i++) {
>                 table->entry[i].ucVco_setting = psmu_info->asSclkFcwRangeEntry[i].ucVco_setting;
>                 table->entry[i].ucPostdiv = psmu_info->asSclkFcwRangeEntry[i].ucPostdiv;
> --
> 2.43.0
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-15  7:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-14 13:29 [PATCH] drm/amd/pm: bound SCLK FCW range entries to the table size Hari Mishal
2026-09-14 13:55 ` sashiko-bot
2026-09-14 16:00 ` Alex Deucher

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.