From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 14A8CF4613D for ; Tue, 24 Mar 2026 09:12:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 08A3F10E63D; Tue, 24 Mar 2026 09:12:25 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=139.com header.i=@139.com header.b="vzOqwIND"; dkim-atps=neutral X-Greylist: delayed 560 seconds by postgrey-1.36 at gabe; Tue, 24 Mar 2026 01:01:30 UTC Received: from n169-110.mail.139.com (d255-143.mail.139.com [36.138.255.143]) by gabe.freedesktop.org (Postfix) with ESMTP id 13BD510E2AB; Tue, 24 Mar 2026 01:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=139.com; s=dkim; l=0; h=from:subject:message-id:to:cc:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=vzOqwINDB91eV8+Xm8AYdJubgN2sv0Ozjh4V8rnqN+AbLd3z5AEVMBufOsr6WslFWxkSD/rqqMky9 YbKHpJkK/VDWWeoQEqkEKscEMnwc69zwMFQLb6QT+ycKa6x3NZ9NKfDv2DqwtQ0VWN50FFmu0KY7C1 zcWQPT5nr4bnc2dI= X-RM-SAVE-FROM: 1 X-RM-SPAM-FLAG: 00000000 Received: from 1468888505@139.com ( [60.247.85.88] ) by ajax-webmail-appmail_28-11028 (Richmail) with HTTP; Tue, 24 Mar 2026 08:52:01 +0800 (CST) Date: Tue, 24 Mar 2026 08:52:01 +0800 (CST) From: 18801328227 <1468888505@139.com> To: Greg KH , =?utf-8?Q?ChristianK=C3=B6nig=20?= Cc: cve , "srinivasan.shanmugam " , patches , linux-kernel , "alexander.deucher " , "Xinhui.Pan " , airlied , daniel , sashal , "guchun.chen " , amd-gfx , dri-devel Message-ID: <2b1469c1e031aed-00001.Richmail.02090755151412502065@139.com> References: <20260323071052.4068410-1-1468888505@139.com> <2026032346-ruse-dork-baf3@gregkh> , <2026032335-muster-chump-60f7@gregkh> Subject: Re:Re: [PATCH 6.1.y] drm/amdgpu: Fix potential out-of-bounds access in'amdgpu_discovery_reg_base_init()' MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7137_44425550.1774313521908" X-Priority: 3 X-RM-TRANSID: 2b1469c1e031aed-00001 X-RM-OA-ENC-TYPE: 0 X-RM-FontColor: 0 X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0 X-Mailer: Richmail_Webapp(V2.5.32) X-Mailman-Approved-At: Tue, 24 Mar 2026 09:12:22 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" ------=_Part_7137_44425550.1774313521908 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg & Christian, Thanks for pointing this out. You are correct! I submitted this patch solel= y to fix CVE-2024-27042. I am happy to withdraw it. Thanks a lot. ---------------------------------------------------------------------------= ----- ----The following is the content of the forwarded email---- From=EF=BC=9AGreg KH=20 To=EF=BC=9A"ChristianK=C3=B6nig"=20 Date=EF=BC=9A2026-03-23 20:37:46 Subject=EF=BC=9ARe: [PATCH 6.1.y] drm/amdgpu: Fix potential out-of-bounds a= ccess in'amdgpu_discovery_reg_base_init()' On Mon, Mar 23, 2026 at 01:28:24PM +0100, Christian K=C3=B6nig wrote: > Hi Greg, >=20 > On 3/23/26 11:32, Greg KH wrote: > > On Mon, Mar 23, 2026 at 10:51:18AM +0100, Christian K=C3=B6nig wrote: > >> Hi Li, > >> > >> On 3/23/26 08:10, Li hongliang wrote: > >>> From: Srinivasan Shanmugam=20 > >>> > >>> [ 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. Thi= s > >>> ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the arr= ay > >>> before it is used as an index. > >>> > >>> Fixes the below: > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_r= eg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after u= se. > >> > >> well this patch only fixed a compiler warning and has not much practic= al value otherwise. > >> > >> Why are you sending this for inclusion into the 6.1 kernel? > >=20 > > 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. >=20 > Thanks a lot for pointing that out, adding cve@kernel.org. >=20 > As far as I can see the CVE-2024-27042 is not valid or at least not corre= ctly categorized. >=20 > 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 f= lash EEPROM located on the HW and not user input. >=20 > If an attacker already had the ability to modify that EEPROM he could jus= t overwrite the VBIOS code were parts are directly executed at bootup and/o= r driver load. So this problem here wouldn't be needed at all. >=20 > It is good that this warning is fixed, but as far as I can see there is n= o reason whatsoever to backport it nor to assign a CVE entry for it. Now rejected, thanks! greg k-h ------=_Part_7137_44425550.1774313521908 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg & Christian,
Thanks for pointing this out. Y= ou are correct! I submitted this patch solely to fix CVE-2024-27042. I am=  happy to withdraw it. Thanks a lot.


<= hr id=3D"replySplit" style=3D"font-family: =E5=BE=AE=E8=BD=AF=E9=9B=85=E9= =BB=91; font-size: 16px; color: rgb(0, 0, 0); line-height: 1.5;">
----The following is the content o= f the forwarded email---- From=EF=BC=9AGreg KH To=EF=BC=9A"ChristianK=C3=B6nig" Date=EF=BC=9A2026-03-23 20:37:46 Subject=EF=BC=9ARe: [PATCH 6.1.y] drm/amdgpu: Fix potential out-of-bounds a= ccess in'amdgpu_discovery_reg_base_init()' On Mon, Mar 23, 2026 at 01:28:24PM +0100, Christian K=C3=B6nig wrote: > Hi Greg, >=20 > On 3/23/26 11:32, Greg KH wrote: > > On Mon, Mar 23, 2026 at 10:51:18AM +0100, Christian K=C3=B6nig wr= ote: > >> Hi Li, > >> > >> On 3/23/26 08:10, Li hongliang wrote: > >>> From: Srinivasan Shanmugam > >>> > >>> [ Upstream commit cdb637d339572398821204a1142d8d615668f1e= 9 ] > >>> > >>> 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 bo= unds 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_vc= n_inst' after use. > >> > >> well this patch only fixed a compiler warning and has not muc= h practical value otherwise. > >> > >> Why are you sending this for inclusion into the 6.1 kernel? > >=20 > > Perhaps because it was assigned to CVE-2024-27042? If this is ON= LY a > > compiler warning fix, and NOT an actual vulnerability fix, please= let > > cve@kernel.org know about that and they will revoke this CVE. >=20 > Thanks a lot for pointing that out, adding cve@kernel.org. >=20 > As far as I can see the CVE-2024-27042 is not valid or at least not co= rrectly categorized. >=20 > It is correct that there is a potential array overrun in amdgpu_discov= ery_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. >=20 > 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 an= d/or driver load. So this problem here wouldn't be needed at all. >=20 > It is good that this warning is fixed, but as far as I can see there i= s no reason whatsoever to backport it nor to assign a CVE entry for it. Now rejected, thanks! greg k-h





------=_Part_7137_44425550.1774313521908--