Re: Patch "drm/tegra: fbdev: Remove offset into framebuffer memory" has been added to the 6.1-stable tree

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] An integer underflow in the `tegra_fb_create` plane size calculation allows an attacker to bypass GEM object bounds checks, leading to an out-of-bounds DMA read by the display controller.
--

--- Patch [1]: Patch "drm/tegra: fbdev: Remove offset into framebuffer memory" has been added to the 6.1-stable tree ---
commit 696762710748d2e202ebca2f2997d6adca30bffb
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>

Patch "drm/tegra: fbdev: Remove offset into framebuffer memory" has been added to the 6.1-stable tree

The screen_buffer field in struct fb_info contains the kernel address
of the first byte of framebuffer memory. Do not add the display offset.
This offset only describes scrolling during scanout.

Link: https://patch.msgid.link/20260421073646.144712-3-tzimmermann@suse.de

> diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> index 9291209154a7a..0e908e7f7b721 100644
> --- a/drivers/gpu/drm/tegra/fb.c
> +++ b/drivers/gpu/drm/tegra/fb.c

[Severity: High]
This isn't a bug introduced by this patch, but does an integer underflow in
tegra_fb_create() allow bypassing GEM object bounds checks?

If a user calls DRM_IOCTL_MODE_ADDFB2 with cmd->height = 1 and a subsampled
pixel format (like YUV420 where vsub = 2), the plane height calculation
evaluates to 0:

    unsigned int height = cmd->height / (i ? info->vsub : 1);

Then, the size computation evaluates to:

    size = (height - 1) * cmd->pitches[i] +
           width * bpp + cmd->offsets[i];

Because height is 0, (height - 1) underflows to UINT_MAX. In 32-bit
arithmetic, UINT_MAX * pitches[i] is equivalent to -pitches[i], which can
result in a small positive size if an attacker supplies specifically crafted
pitches and offsets.

This artificially small size easily passes the bounds check:

    if (gem->size < size) {
        err = -EINVAL;
        goto unreference;
    }

The display controller could then be programmed with bo->iova + offsets[i],
pointing far beyond the GEM object's bounds, which may lead to an
out-of-bounds DMA read.

> @@ -267,9 +266,6 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
>  
>  	drm_fb_helper_fill_info(info, helper, sizes);
>  
> -	offset = info->var.xoffset * bytes_per_pixel +
> -		 info->var.yoffset * fb->pitches[0];
> -

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026082007-trouble-unscrew-aa17@gregkh?part=1