From: sashiko-bot@kernel.org
To: "Jonathan Frazin" <frazinjonathan@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 2/2] drm/tiny: allow a framebuffer larger than the panel on MIPI DBI drivers
Date: Thu, 10 Sep 2026 19:05:42 +0000 [thread overview]
Message-ID: <20260910190542.BE6AE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910185030.870-3-frazinjonathan@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Heap buffer overflow in MIPI DBI transmit buffer due to fractional source coordinates.
--
commit 4a10bf379a1886aa47defe01dc700836d3b28773
Author: Jonathan Frazin <frazinjonathan@gmail.com>
drm/tiny: allow a framebuffer larger than the panel on MIPI DBI drivers
This commit raises the max_width and max_height for several MIPI DBI
drivers to DRM_SHADOW_PLANE_MAX_WIDTH/HEIGHT. This allows userspace to
allocate larger framebuffers and use the plane source rectangle to
pan without scaling.
> diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
> index 60cd65cae41d8..a0a098b0da8a3 100644
> --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c
> +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
[ ... ]
> @@ -448,9 +448,13 @@ static int panel_mipi_dbi_spi_probe(struct spi_device *spi)
> return ret;
>
> drm->mode_config.min_width = dbidev->mode.hdisplay;
> - drm->mode_config.max_width = dbidev->mode.hdisplay;
> + /*
> + * Allow a framebuffer larger than the panel so a sub-region can be
> + * displayed via the plane source rectangle (crop / pan, no scaling).
> + */
> + drm->mode_config.max_width = DRM_SHADOW_PLANE_MAX_WIDTH;
[Severity: Critical]
Can this change cause a heap buffer overflow in mipi_dbi_fb_dirty()?
By allowing the framebuffer to be larger than the panel, userspace can now
use non-zero source offsets. If userspace provides fractional source
coordinates via the atomic ioctl, the damage iterator will round the
coordinates outwards (floor and ceil).
This can result in a merged damage rectangle that is larger than the
physical panel dimensions, which gets passed to
drm_mipi_dbi_plane_helper_atomic_update():
drivers/gpu/drm/drm_mipi_dbi.c:drm_mipi_dbi_plane_helper_atomic_update() {
...
if (drm_atomic_helper_damage_merged(old_plane_state, plane_state, &rect))
mipi_dbi_fb_dirty(&shadow_plane_state->data[0], fb, &rect,
...
}
Then in mipi_dbi_fb_dirty(), the inflated rectangle is used to compute the
copy bounds:
drivers/gpu/drm/drm_mipi_dbi.c:mipi_dbi_fb_dirty() {
...
unsigned int height = rect->y2 - rect->y1;
unsigned int width = rect->x2 - rect->x1;
...
ret = mipi_dbi_buf_copy(tr, src, fb, rect, swap, fmtcnv_state);
...
}
Since tx_buf was strictly allocated during drm_mipi_dbi_dev_init() to hold
exactly the panel size, copying based on this inflated width and height will
overflow tx_buf on the heap.
> drm->mode_config.min_height = dbidev->mode.vdisplay;
> - drm->mode_config.max_height = dbidev->mode.vdisplay;
> + drm->mode_config.max_height = DRM_SHADOW_PLANE_MAX_HEIGHT;
> drm->mode_config.funcs = &panel_mipi_dbi_mode_config_funcs;
> drm->mode_config.preferred_depth = bpp;
> drm->mode_config.helper_private = &panel_mipi_dbi_mode_config_helper_funcs;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260910185030.870-1-frazinjonathan@gmail.com?part=2
next prev parent reply other threads:[~2026-09-10 19:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 18:48 [PATCH v1 0/2] drm/mipi-dbi: display a cropped region of an oversized framebuffer Jonathan Frazin
2026-09-10 18:48 ` [PATCH v1 1/2] drm/mipi-dbi: honour the plane source offset when flushing Jonathan Frazin
2026-09-10 19:07 ` sashiko-bot
2026-09-10 18:48 ` [PATCH v1 2/2] drm/tiny: allow a framebuffer larger than the panel on MIPI DBI drivers Jonathan Frazin
2026-09-10 19:05 ` sashiko-bot [this message]
2026-09-11 0:19 ` Jonathan Frazin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260910190542.BE6AE1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frazinjonathan@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.