Re: [PATCH] drm/nouveau: validate MXMS descriptor bounds

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing validation of the ACPI WMI evaluation output can cause a NULL pointer dereference.
--

commit d046b4257d93287fd7148175e8bfb0fc2ce27ed6
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

drm/nouveau: validate MXMS descriptor bounds

This commit adds bounds checking for MXMS descriptors. It retains the provider
buffer size with the MXMS data, validates fixed headers, and verifies
descriptor arrays against the remaining buffer size.

> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c
> index 26ec50b66e667..ad74a216a201d 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c

[ ... ]

> @@ -188,6 +201,8 @@ mxm_shadow_wmi(struct nvkm_mxm *mxm, u8 version)
>  	if (obj->type == ACPI_TYPE_BUFFER) {

[Severity: High]
This is a pre-existing issue, but can wmi_evaluate_method() return success
while leaving retn.pointer as NULL?

If the BIOS WMI implementation returns void, obj (assigned from retn.pointer
just before this block) would be NULL. Does this code risk a NULL pointer
dereference around line 197 when accessing obj->type in mxm_shadow_wmi() in
base.c without verifying the pointer first?

A similar condition appears to exist around line 153 in wmi_wmmx_mxmi() where
retn.pointer is also dereferenced without validation.

>  		mxm->mxms = kmemdup(obj->buffer.pointer,
>  				    obj->buffer.length, GFP_KERNEL);
> +		if (mxm->mxms)
> +			mxm->mxms_size = obj->buffer.length;
>  	}
>  
>  	kfree(obj);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706093949.82126-1-pengpeng@iscas.ac.cn?part=1