Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] 32-bit integer overflow in `height * stride` calculation causes truncated visible size for framebuffers >4GB, leading to out-of-bounds kernel memory accesses. -- commit e0fef2d92fd416a597acb169f1514b97e1eff546 Author: Thomas Zimmermann <[email protected]> drm/sysfb: Do not page-align visible size of the framebuffer This commit stops page-aligning the visible size of the system framebuffer in drm_sysfb_get_visible_size_si(). Drivers use this size value for reserving access to framebuffer memory, and increasing the value can make later attempts to reserve memory fail. > diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > b/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > --- a/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > +++ b/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > @@ -67,7 +67,7 @@ EXPORT_SYMBOL(drm_sysfb_get_stride_si); > u64 drm_sysfb_get_visible_size_si(struct drm_device *dev, const struct > screen_info *si, > unsigned int height, unsigned int stride, u64 > size) > { > - u64 vsize = PAGE_ALIGN(height * stride); > + u64 vsize = height * stride; [Severity: High] This is a pre-existing issue, but does this calculation overflow on 32-bit arithmetic before assignment? Both height and stride are passed as unsigned int. If the system provides a framebuffer resource larger than 4GB, the height * stride product could overflow and truncate before being zero-extended to u64 vsize. This truncated value could pass validation against the resource bounds and lead to an undersized devm_ioremap_wc(). Could this cause out-of-bounds kernel memory accesses during subsequent DRM operations, such as drm_fb_memcpy(), if they iterate using the original non-truncated dimensions? > > return drm_sysfb_get_validated_size0(dev, "visible size", vsize, size); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
