Patch "drm/sysfb: Do not page-align visible size of the framebuffer" has been added to the 6.18-stable tree

Patch "drm/sysfb: Do not page-align visible size of the framebuffer" has been added to the 6.18-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    drm/sysfb: Do not page-align visible size of the framebuffer

to the 6.18-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-sysfb-do-not-page-align-visible-size-of-the-framebuffer.patch
and it can be found in the queue-6.18 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


From 134844856c399bfa9462a159dcf860bfdb748055 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Thu, 18 Jun 2026 10:41:57 +0200
Subject: drm/sysfb: Do not page-align visible size of the framebuffer

From: Thomas Zimmermann <tzimmermann@suse.de>

commit 134844856c399bfa9462a159dcf860bfdb748055 upstream.

Only return the actually visible size of the system framebuffer in
drm_sysfb_get_visible_size_si(). Drivers use this size value for
reserving access to framebuffer memory. Increasing the value can
make later attempts to do so fail.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays")
Fixes: a84eb6abe2b6 ("drm/sysfb: Add vesadrm for VESA displays")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.16+
Link: https://patch.msgid.link/20260618084327.46567-2-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpu/drm/sysfb/drm_sysfb_screen_info.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 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;
 
 	return drm_sysfb_get_validated_size0(dev, "visible size", vsize, size);
 }


Patches currently in stable-queue which might be from tzimmermann@suse.de are

queue-6.18/drm-tests-shmem-set-dma-mask-to-64-bit-in-drm_gem_sh.patch
queue-6.18/drm-sysfb-avoid-possible-truncation-with-calculating-visible-size.patch
queue-6.18/drm-sysfb-do-not-page-align-visible-size-of-the-framebuffer.patch
queue-6.18/drm-sysfb-return-errno-code-from-drm_sysfb_get_visible_size.patch
queue-6.18/drm-sysfb-avoid-truncating-maximum-stride.patch

Re: Patch "drm/sysfb: Do not page-align visible size of the framebuffer" has been added to the 6.18-stable tree

[sashiko-bot]

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: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>

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/20260618084327.46567-2-tzimmermann@suse.de

> 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