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

[Greg KH <gregkh@linuxfoundation.org>]

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 <srinivasan.shanmugam@amd.com>
> >>>
> >>> [ 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