Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] ast: commit message and code mismatch regarding DP501 bounds check --
commit 7c7f87df86011f4f2e1f7815297b6468c2302228 Author: Hui Peng <[email protected]> drm/ast: validate framebuffer VRAM size in ast_mode.c and DP501 firmware bounds This commit adds bounds checking for the primary plane framebuffer size against the vram_size. It also updates the DP501 firmware copy loop in ast_dp501.c to prevent out-of-bounds memory accesses. > In drivers/gpu/drm/ast/ (ast_mode.c, ast_dp501.c), verify that the > primary plane framebuffer fits within ast->vram_size and bounds-check > DP501 firmware headers. > diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c > index 6d6ccfad14154..d9ca8760e5b51 100644 > --- a/drivers/gpu/drm/ast/ast_dp501.c > +++ b/drivers/gpu/drm/ast/ast_dp501.c > @@ -250,7 +250,8 @@ static bool ast_launch_m68k(struct ast_device *ast) > > /* copy image to buffer */ > for (i = 0; i < len; i += 4) { > - data = *(u32 *)(fw_addr + i); > + data = 0; > + memcpy(&data, fw_addr + i, min_t(u32, len - i, 4)); [Severity: Medium] Is the commit message accurate regarding DP501 firmware headers? The commit message claims to "bounds-check DP501 firmware headers", but ast_launch_m68k() adds a bounds check to the firmware payload copy loop instead. Since the driver reads DP501 headers directly from mapped hardware memory rather than the host buffer, there are no headers in the host buffer to bounds-check. Could the commit message be updated to describe this payload copy bounds check instead of firmware headers? > ast_moutdwm(ast, boot_address + i, data); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
