Hi Greg & Christian,

Thanks for pointing this out. You are correct! I submitted this patch solely to fix CVE-2024-27042. I am happy to withdraw it. Thanks a lot.






--------------------------------------------------------------------------------


----The following is the content of the forwarded email----
From：Greg KH 
To："ChristianKönig" 
Date：2026-03-23 20:37:46
Subject：Re: [PATCH 6.1.y] drm/amdgpu: Fix potential out-of-bounds access in'amdgpu_discovery_reg_base_init()'

On Mon, Mar 23, 2026 at 01:28:24PM +0100, Christian König wrote:
> 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 
> >>>
> >>> [ 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@kernel.org know about that and they will revoke this CVE.
> 
> Thanks a lot for pointing that out, adding cve@kernel.org.
> 
> 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.

Now rejected, thanks!

greg k-h