Re: [PATCH 6.1.y] drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

[Christian König]

Hi Greg,

On 3/23/26 11:32, Greg KH wrote:
> On Mon, Mar 23, 2026 at 10:51:18AM +0100, Christian König wrote:
>> Hi Li,
>>
>> On 3/23/26 08:10, Li hongliang wrote:
>>> From: Srinivasan Shanmugam <srinivasan.shanmugam@xxxxxxx>
>>>
>>> [ Upstream commit cdb637d339572398821204a1142d8d615668f1e9 ]
>>>
>>> The issue arises when the array 'adev->vcn.vcn_config' is accessed
>>> before checking if the index 'adev->vcn.num_vcn_inst' is within the
>>> bounds of the array.
>>>
>>> The fix involves moving the bounds check before the array access. This
>>> ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array
>>> before it is used as an index.
>>>
>>> Fixes the below:
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use.
>>
>> well this patch only fixed a compiler warning and has not much practical value otherwise.
>>
>> Why are you sending this for inclusion into the 6.1 kernel?
> 
> Perhaps because it was assigned to CVE-2024-27042?  If this is ONLY a
> compiler warning fix, and NOT an actual vulnerability fix, please let
> cve@xxxxxxxxxx know about that and they will revoke this CVE.

Thanks a lot for pointing that out, adding cve@xxxxxxxxxx.

As far as I can see the CVE-2024-27042 is not valid or at least not correctly categorized.

It is correct that there is a potential array overrun in amdgpu_discovery_reg_base_init(), but that function is used to parse a VBIOS table from a flash EEPROM located on the HW and not user input.

If an attacker already had the ability to modify that EEPROM he could just overwrite the VBIOS code were parts are directly executed at bootup and/or driver load. So this problem here wouldn't be needed at all.

It is good that this warning is fixed, but as far as I can see there is no reason whatsoever to backport it nor to assign a CVE entry for it.

Regards,
Christian.

> 
> thanks,
> 
> greg k-h