Re: [PATCH v5] drm/fbdev-generic: prohibit potential out-of-bounds access

From: Geert Uytterhoeven
Date: Thu Apr 20 2023 - 10:22:05 EST


Hi Thomas,

On Thu, Apr 20, 2023 at 2:59 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> Am 20.04.23 um 14:25 schrieb Geert Uytterhoeven:
> > On Thu, Apr 20, 2023 at 1:10 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> >> Am 20.04.23 um 12:04 schrieb Sui Jingfeng:
> >>> What will happen if the 'screen_size' is not page_size aligned and mmap
> >>> will mapping in the granularity of pages ?
> >>
> >> You need to map at page granularity. If screen_size is not page-size
> >> aligned, there's this trailing buffer that is accessible, but cannot be
> >> displayed. But userspace has no direct way of knowing that, so let's
> >> ignore that problem for now.
> >
> > Userspace can know, if fb_fix_screeninfo.smem_{start,len} match
> > the actual offset and size.
>
> Can you elaborate? How can userspace detect/compute the actually usable
> space?

By looking at fb_fix_screeninfo.smem_{start,len}, which are the (physical)
address and length of the frame buffer.

> From grep'ing fbdev drivers, smem_len appears to be a multiple of the
> pagesize. (?) screen_size is not exported and line_length in the fixed
>
> portion. Or can line_length change between modes? In that case it should
> be (yres_virtual * line_length), right?

smem_{start,len} are not guaranteed to be page-aligned.
Fbtest[1] and Xorg should handle that fine.

line_length can change between modes. It's part of fb_fix_screeninfo,
because it's fixed in the sense that it depends on the video mode, and
the user cannot specify its value.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git/tree/fb.c#n199

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