Bug 108609

Summary: vegam_smumgr.c: accessing mvdd_voltage_table.entries[] array out of bounds in function vegam_populate_smc_mvdd_table
Product: DRI Reporter: Robert Strube <rstrube>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Patch to fix accessing mvdd_voltage_table.entries[] array out of bounds in vegam_smumgr.c none

Description Robert Strube 2018-10-31 06:55:41 UTC
Created attachment 142298 [details] [review]
Patch to fix accessing mvdd_voltage_table.entries[] array out of bounds in vegam_smumgr.c

I believe I've discovered a small bug in the vegam_smumgr.c, specifically the following function:

static int vegam_populate_smc_mvdd_table(struct pp_hwmgr *hwmgr,
			SMU75_Discrete_DpmTable *table)
{
	struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
	uint32_t count, level;

	if (SMU7_VOLTAGE_CONTROL_BY_GPIO == data->mvdd_control) {
		count = data->mvdd_voltage_table.count;
		if (count > SMU_MAX_SMIO_LEVELS)
			count = SMU_MAX_SMIO_LEVELS;
		for (level = 0; level < count; level++) {
			table->SmioTable2.Pattern[level].Voltage = PP_HOST_TO_SMC_US(
					data->mvdd_voltage_table.entries[count].value * VOLTAGE_SCALE);
			/* Index into DpmTable.Smio. Drive bits from Smio entry to get this voltage level.*/
			table->SmioTable2.Pattern[level].Smio =
				(uint8_t) level;
			table->Smio[level] |=
				data->mvdd_voltage_table.entries[level].smio_low;
		}
		table->SmioMask2 = data->mvdd_voltage_table.mask_low;

		table->MvddLevelCount = (uint32_t) PP_HOST_TO_SMC_UL(count);
	}

	return 0;
}

With the lines (within the for loop):

table->SmioTable2.Pattern[level].Voltage = PP_HOST_TO_SMC_US(
		data->mvdd_voltage_table.entries[count].value * VOLTAGE_SCALE);

If this code was executed it would try to access the mvdd_voltage_table.entries[] array out of bounds, because count > than the max value for level.

I believe:

data->mvdd_voltage_table.entries[count].value

should actually be:

data->mvdd_voltage_table.entries[level].value

You can see in a similar function within vegam_smumgr.c, this bug is *not* present:

static int vegam_populate_smc_vddci_table(struct pp_hwmgr *hwmgr,
					struct SMU75_Discrete_DpmTable *table)
{
	uint32_t count, level;
	struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);

	count = data->vddci_voltage_table.count;

	if (SMU7_VOLTAGE_CONTROL_BY_GPIO == data->vddci_control) {
		if (count > SMU_MAX_SMIO_LEVELS)
			count = SMU_MAX_SMIO_LEVELS;
		for (level = 0; level < count; ++level) {
			table->SmioTable1.Pattern[level].Voltage = PP_HOST_TO_SMC_US(
					data->vddci_voltage_table.entries[level].value * VOLTAGE_SCALE);
			table->SmioTable1.Pattern[level].Smio = (uint8_t) level;

			table->Smio[level] |= data->vddci_voltage_table.entries[level].smio_low;
		}
	}

	table->SmioMask1 = data->vddci_voltage_table.mask_low;

	return 0;
}

I've attached a patch for kernel 4.19, admittedly the change is trivial but I figured I would try to do things the right way :)

Thanks!
Rob
Comment 1 Michel Dänzer 2018-10-31 08:47:17 UTC
Please send the patch (generated by git format-patch) to the amd-gfx mailing list for review.
Comment 2 Robert Strube 2018-10-31 22:59:31 UTC
What repo and branch do you want the patch made against?  Does AMD have it's own  repo for the linux kernel, or should I go against: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master branch?
Comment 4 Martin Peres 2019-11-19 09:01:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/582.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.