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

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

[Li hongliang]

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.

Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances")
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ Minor conflict resolved. ]
Signed-off-by: Li hongliang <1468888505@139.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 9b1c4d5be61f..a1e006d238cf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -1128,15 +1128,15 @@ static int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev)
 				 *     0b10 : encode is disabled
 				 *     0b01 : decode is disabled
 				 */
-				adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
-					ip->revision & 0xc0;
-				ip->revision &= ~0xc0;
-				if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES)
+				if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) {
+					adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
+						ip->revision & 0xc0;
 					adev->vcn.num_vcn_inst++;
-				else
+				} else
 					dev_err(adev->dev, "Too many VCN instances: %d vs %d\n",
 						adev->vcn.num_vcn_inst + 1,
 						AMDGPU_MAX_VCN_INSTANCES);
+				ip->revision &= ~0xc0;
 			}
 			if (le16_to_cpu(ip->hw_id) == SDMA0_HWID ||
 			    le16_to_cpu(ip->hw_id) == SDMA1_HWID ||
-- 
2.34.1

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

[Christian König]

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?

Regards,
Christian.

> 
> Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances")
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> [ Minor conflict resolved. ]
> Signed-off-by: Li hongliang <1468888505@139.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 9b1c4d5be61f..a1e006d238cf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -1128,15 +1128,15 @@ static int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev)
>  				 *     0b10 : encode is disabled
>  				 *     0b01 : decode is disabled
>  				 */
> -				adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
> -					ip->revision & 0xc0;
> -				ip->revision &= ~0xc0;
> -				if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES)
> +				if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) {
> +					adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
> +						ip->revision & 0xc0;
>  					adev->vcn.num_vcn_inst++;
> -				else
> +				} else
>  					dev_err(adev->dev, "Too many VCN instances: %d vs %d\n",
>  						adev->vcn.num_vcn_inst + 1,
>  						AMDGPU_MAX_VCN_INSTANCES);
> +				ip->revision &= ~0xc0;
>  			}
>  			if (le16_to_cpu(ip->hw_id) == SDMA0_HWID ||
>  			    le16_to_cpu(ip->hw_id) == SDMA1_HWID ||

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

[Greg KH]

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,

greg k-h

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@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.

Regards,
Christian.

> 
> thanks,
> 
> greg k-h

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

[Greg KH]

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

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

[18801328227]

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]



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















[-- Attachment #2: Type: text/html, Size: 19005 bytes --]

Claude review: drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

[Claude Code Review Bot]

Overall Series Review

Subject: drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'
Author: Li hongliang <1468888505@139.com>
Patches: 6
Reviewed: 2026-03-25T08:02:38.488122

---

This is a single-patch stable backport (targeting 6.1.y) of upstream commit `cdb637d339572398821204a1142d8d615668f1e9`, which fixes a potential out-of-bounds array access in `amdgpu_discovery_reg_base_init()`. The original fix was authored by Srinivasan Shanmugam and reviewed by Alex Deucher. The backport submitter (Li hongliang) notes a minor conflict was resolved.

The core idea is correct: the bounds check on `adev->vcn.num_vcn_inst` must happen **before** using it as an array index into `vcn_config[]`, not after.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

[Claude Code Review Bot]

Patch Review

**The fix is correct in principle** — it moves the bounds check before the array write, preventing OOB access. However, there is a subtle behavioral difference from the upstream version:

**Issue 1: `ip->revision &= ~0xc0` moved outside the bounds check**

In the original (pre-fix) code:
```c
adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
    ip->revision & 0xc0;
ip->revision &= ~0xc0;
if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES)
    adev->vcn.num_vcn_inst++;
```

The `ip->revision &= ~0xc0` clearing always happened regardless of bounds. In the patched code:
```c
if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) {
    adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =
        ip->revision & 0xc0;
    adev->vcn.num_vcn_inst++;
} else
    ...
ip->revision &= ~0xc0;
```

The `ip->revision &= ~0xc0` is placed **after** the if/else, so it still executes unconditionally in both paths. This is correct and preserves the original semantics.

**Issue 2: Missing `inst_mask` updates compared to upstream**

Looking at the current upstream code (drm-next), the fix there also sets `adev->vcn.inst_mask` and `adev->jpeg.inst_mask` inside the bounds-checked block, and the field was refactored from `adev->vcn.vcn_config[]` to `adev->vcn.inst[].vcn_config`. These differences are expected since this is a 6.1.y backport targeting an older kernel with a different data structure, so this is fine.

**Issue 3: Style nit — asymmetric braces**

```c
if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) {
    ...
} else
    dev_err(...);
```

Per kernel coding style, when one branch of an if/else uses braces, both should. This should be:
```c
} else {
    dev_err(...);
}
```

This is a minor style issue that was actually present in the original code too (the `else` branch had no braces), so it's not a regression from this patch.

**Verdict**: The backport is functionally correct and appropriate for 6.1.y stable. The OOB fix is sound — the array write is now properly guarded. The conflict resolution appears to have been done correctly, preserving the original semantics of always clearing the revision bits. No functional concerns.

---
Generated by Claude Code Patch Reviewer