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 > > [email protected] know about that and they will revoke this CVE. > > Thanks a lot for pointing that out, adding [email protected]. > > 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
