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 <[email protected]> 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/[email protected]?part=1
