Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues: - [High] A 32-bit integer overflow in the `height * stride` calculation leads to a truncated mapping size, allowing a massive out-of-bounds write. - [Medium] `drm_sysfb_get_validated_size0()` returns an `s64` error code (`-EINVAL`), which is implicitly cast to a huge positive `u64` value in `drm_sysfb_get_visible_size_si()`, bypassing caller error checks. -- --- Patch [1]: Patch "drm/sysfb: Do not page-align visible size of the framebuffer" has been added to the 6.18-stable tree --- commit 73e7b8e3b5af9020895060aed292665597f1df3d Author: [email protected] <[email protected]> Patch "drm/sysfb: Do not page-align visible size of the framebuffer" has been added to the 6.18-stable tree This commit is a stable backport of a patch that stops page-aligning the visible size of the system framebuffer in drm_sysfb_get_visible_size_si(). Only the actually visible size is returned. Link: https://patch.msgid.link/[email protected] > diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > b/drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c > index 885864168c54f..ebcb28f2b3359 100644 > --- 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 isn't a bug introduced by this patch, but does the multiplication of height and stride overflow here? Both height and stride are unsigned int, so their multiplication is a 32-bit operation that can overflow before being zero-extended to u64, resulting in a truncated vsize. This could allow a truncated size to pass validation, while subsequent code (like the DRM damage worker) uses the full dimensions, leading to a massive out-of-bounds write in kernel virtual memory if malicious screen_info parameters are provided by a bootloader or hypervisor. > > return drm_sysfb_get_validated_size0(dev, "visible size", vsize, size); [Severity: Medium] This is a pre-existing issue, but does this implicit cast to u64 bypass caller error checks? drm_sysfb_get_validated_size0() can return an s64 error code like -EINVAL. Since drm_sysfb_get_visible_size_si() returns a u64, this negative value becomes a huge positive number. Callers fail to catch this because they only check for zero: drivers/gpu/drm/sysfb/efidrm.c:efidrm_device_create() { ... if (!vsize) return ERR_PTR(-EINVAL); ... } Should the return type of drm_sysfb_get_visible_size_si() be s64? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/2026072945-illusive-shut-752a@gregkh?part=1
