Hi Thomas,
On Tue, 21 Jun 2022, Thomas Zimmermann wrote:
Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.
Fbdev's deferred I/O can only track pages. From the range of pages, the
damage handler computes the clipping rectangle for the display update.
If the fbdev screen buffer ends near the beginning of a page, that page
could contain more scanlines. The damage handler would then track these
non-existing scanlines as dirty and provoke an out-of-bounds access
during the screen update. Hence, clip the maximum memory range to the
size of the screen buffer.
While at it, rename the variables min/max to min_off/max_off in
drm_fb_helper_deferred_io(). This avoids confusion with the macros of
the same name.
Reported-by: Nuno Gonçalves <nunojpg@xxxxxxxxx>
Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
Tested-by: Nuno Gonçalves <nunojpg@xxxxxxxxx>
Fixes: 67b723f5b742 ("drm/fb-helper: Calculate damaged area in separate helper")
Thanks for your patch, which is now commit ae25885bdf59fde4
("drm/fb-helper: Fix out-of-bounds access") in drm-misc/for-linux-next.
I had seen the crash before, but thought it was a bug in my wip
atari-drm driver. When diving deeper today, and consequently looking
for recent changes to the damage helper, I found this commit in
linux-next.
With your patch instead of my own workaround I used this morning, [1]
still works fine, so:
Tested-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>.
Reviewed-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>.
[1] [PATCH] drm/fb-helper: Remove helpers to change frame buffer config
https://lore.kernel.org/all/20220629105658.1373770-1-geert@xxxxxxxxxxxxxx
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
