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@gmail.com Signed-off-by: Thomas Zimmermann tzimmermann@suse.de Tested-by: Nuno Gonçalves nunojpg@gmail.com 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@linux-m68k.org. Reviewed-by: Geert Uytterhoeven geert@linux-m68k.org.
[1] [PATCH] drm/fb-helper: Remove helpers to change frame buffer config https://lore.kernel.org/all/20220629105658.1373770-1-geert@linux-m68k.org
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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