* [PATCH v2] fbdev: vfb: Validate framebuffer geometry and memory size
@ 2026-10-26 15:46 Weiming Shi
2026-10-26 16:06 ` Helge Deller
0 siblings, 1 reply; 3+ messages in thread
From: Weiming Shi @ 2026-10-26 15:46 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, dri-devel, linux-kernel, co+b0df61d49532b2ee,
Xiang Mei, Weiming Shi, stable
FBIOPUT_VSCREENINFO can supply a virtual width large enough to
overflow get_line_length()'s int multiplication and bypass the
video-memory limit, allowing fbcon to write past the framebuffer. The
offset additions can also wrap, while an excessive videomemorysize
module parameter can be truncated when PAGE_ALIGN() is assigned to
unsigned int.
Limit virtual geometry and offsets to 8192 x 8192 and cap video
memory at 512 MiB, keeping the stride, framebuffer-size, and generic
fbdev drawing calculations within their destination types.
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in sys_fillrect
drivers/video/fbdev/core/sysfillrect.c:24
Write of size 8 at addr ffa0000001671000 by task poc/198
sys_fillrect
drivers/video/fbdev/core/sysfillrect.c:24
bit_clear_margins
drivers/video/fbdev/core/bitblit.c:247
fbcon_clear_margins.constprop.0
drivers/video/fbdev/core/fbcon.c:1410
fbcon_switch
drivers/video/fbdev/core/fbcon.c:2261
redraw_screen
drivers/tty/vt/vt.c:994
fbcon_modechanged
drivers/video/fbdev/core/fbcon.c:2693
fbcon_update_vcs
drivers/video/fbdev/core/fbcon.c:2732
Cc: stable@vger.kernel.org
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: <co+b0df61d49532b2ee@bugs.sh>
Suggested-by: Helge Deller <deller@gmx.de>
Assisted-by: LLM
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
Changes in v2:
- Limit virtual geometry and offsets to 8192 x 8192. This retains 8K mode
support while bounding all generic fbdev drawing calculations.
- Cap videomemorysize at 512 MiB.
- Keep the existing arithmetic types now that all inputs are bounded.
drivers/video/fbdev/vfb.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index de137b2bd..de40ba8c3 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -31,6 +31,9 @@
*/
#define VIDEOMEMSIZE (1*1024*1024) /* 1 MB */
+#define MAX_VIDEOMEMSIZE (512 * 1024 * 1024)
+#define MAX_XRES 8192
+#define MAX_YRES 8192
static void *videomemory;
static u_long videomemorysize = VIDEOMEMSIZE;
@@ -159,6 +162,14 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
else
return -EINVAL;
+ if (var->xres_virtual > MAX_XRES ||
+ var->yres_virtual > MAX_YRES)
+ return -EINVAL;
+
+ if (var->xoffset > MAX_XRES - var->xres ||
+ var->yoffset > MAX_YRES - var->yres)
+ return -EINVAL;
+
if (var->xres_virtual < var->xoffset + var->xres)
var->xres_virtual = var->xoffset + var->xres;
if (var->yres_virtual < var->yoffset + var->yres)
@@ -434,9 +445,13 @@ static int __init vfb_setup(char *options)
static int vfb_probe(struct platform_device *dev)
{
struct fb_info *info;
- unsigned int size = PAGE_ALIGN(videomemorysize);
+ unsigned int size;
int retval = -ENOMEM;
+ if (videomemorysize > MAX_VIDEOMEMSIZE)
+ return -EINVAL;
+ size = PAGE_ALIGN(videomemorysize);
+
/*
* For real video cards we use ioremap.
*/
--
2.56.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] fbdev: vfb: Validate framebuffer geometry and memory size
2026-10-26 15:46 [PATCH v2] fbdev: vfb: Validate framebuffer geometry and memory size Weiming Shi
@ 2026-10-26 16:06 ` Helge Deller
2026-10-26 16:26 ` Weiming Shi
0 siblings, 1 reply; 3+ messages in thread
From: Helge Deller @ 2026-10-26 16:06 UTC (permalink / raw)
To: Weiming Shi
Cc: linux-fbdev, dri-devel, linux-kernel, co+b0df61d49532b2ee,
Xiang Mei, stable
On 10/26/26 16:46, Weiming Shi wrote:
> FBIOPUT_VSCREENINFO can supply a virtual width large enough to
> overflow get_line_length()'s int multiplication and bypass the
> video-memory limit, allowing fbcon to write past the framebuffer. The
> offset additions can also wrap, while an excessive videomemorysize
> module parameter can be truncated when PAGE_ALIGN() is assigned to
> unsigned int.
>
> Limit virtual geometry and offsets to 8192 x 8192 and cap video
> memory at 512 MiB, keeping the stride, framebuffer-size, and generic
> fbdev drawing calculations within their destination types.
>
> KASAN reports:
>
> BUG: KASAN: vmalloc-out-of-bounds in sys_fillrect
> drivers/video/fbdev/core/sysfillrect.c:24
> Write of size 8 at addr ffa0000001671000 by task poc/198
> sys_fillrect
> drivers/video/fbdev/core/sysfillrect.c:24
> bit_clear_margins
> drivers/video/fbdev/core/bitblit.c:247
> fbcon_clear_margins.constprop.0
> drivers/video/fbdev/core/fbcon.c:1410
> fbcon_switch
> drivers/video/fbdev/core/fbcon.c:2261
> redraw_screen
> drivers/tty/vt/vt.c:994
> fbcon_modechanged
> drivers/video/fbdev/core/fbcon.c:2693
> fbcon_update_vcs
> drivers/video/fbdev/core/fbcon.c:2732
>
> Cc: stable@vger.kernel.org
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: <co+b0df61d49532b2ee@bugs.sh>
> Suggested-by: Helge Deller <deller@gmx.de>
> Assisted-by: LLM
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> Changes in v2:
> - Limit virtual geometry and offsets to 8192 x 8192. This retains 8K mode
> support while bounding all generic fbdev drawing calculations.
> - Cap videomemorysize at 512 MiB.
> - Keep the existing arithmetic types now that all inputs are bounded.
>
> drivers/video/fbdev/vfb.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
> index de137b2bd..de40ba8c3 100644
> --- a/drivers/video/fbdev/vfb.c
> +++ b/drivers/video/fbdev/vfb.c
> @@ -31,6 +31,9 @@
> */
>
> #define VIDEOMEMSIZE (1*1024*1024) /* 1 MB */
> +#define MAX_VIDEOMEMSIZE (512 * 1024 * 1024)
> +#define MAX_XRES 8192
> +#define MAX_YRES 8192
>
> static void *videomemory;
> static u_long videomemorysize = VIDEOMEMSIZE;
> @@ -159,6 +162,14 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
> else
> return -EINVAL;
>
> + if (var->xres_virtual > MAX_XRES ||
> + var->yres_virtual > MAX_YRES)
> + return -EINVAL;
> +
> + if (var->xoffset > MAX_XRES - var->xres ||
> + var->yoffset > MAX_YRES - var->yres)
> + return -EINVAL;
Instead of returning EINVAL, I wonder if we could simply
cap the resolutions at MAX_XRES/MAX_YRES?
> +
> if (var->xres_virtual < var->xoffset + var->xres)
> var->xres_virtual = var->xoffset + var->xres;
> if (var->yres_virtual < var->yoffset + var->yres)
> @@ -434,9 +445,13 @@ static int __init vfb_setup(char *options)
> static int vfb_probe(struct platform_device *dev)
> {
> struct fb_info *info;
> - unsigned int size = PAGE_ALIGN(videomemorysize);
> + unsigned int size;
> int retval = -ENOMEM;
>
and here maybe
videomemorysize = min(videomemorysize, MAX_VIDEOMEMSIZE);
that way the driver loads even if the provided too big value?
Helge
> + if (videomemorysize > MAX_VIDEOMEMSIZE)
> + return -EINVAL;
> + size = PAGE_ALIGN(videomemorysize);
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] fbdev: vfb: Validate framebuffer geometry and memory size
2026-10-26 16:06 ` Helge Deller
@ 2026-10-26 16:26 ` Weiming Shi
0 siblings, 0 replies; 3+ messages in thread
From: Weiming Shi @ 2026-10-26 16:26 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, dri-devel, linux-kernel, co+b0df61d49532b2ee,
Xiang Mei, stable
Helge Deller <deller@gmx.de> 于2026年10月26日周一 09:06写道：
>
> On 10/26/26 16:46, Weiming Shi wrote:
> > FBIOPUT_VSCREENINFO can supply a virtual width large enough to
> > overflow get_line_length()'s int multiplication and bypass the
> > video-memory limit, allowing fbcon to write past the framebuffer. The
> > offset additions can also wrap, while an excessive videomemorysize
> > module parameter can be truncated when PAGE_ALIGN() is assigned to
> > unsigned int.
> >
> > Limit virtual geometry and offsets to 8192 x 8192 and cap video
> > memory at 512 MiB, keeping the stride, framebuffer-size, and generic
> > fbdev drawing calculations within their destination types.
> >
> > KASAN reports:
> >
> > BUG: KASAN: vmalloc-out-of-bounds in sys_fillrect
> > drivers/video/fbdev/core/sysfillrect.c:24
> > Write of size 8 at addr ffa0000001671000 by task poc/198
> > sys_fillrect
> > drivers/video/fbdev/core/sysfillrect.c:24
> > bit_clear_margins
> > drivers/video/fbdev/core/bitblit.c:247
> > fbcon_clear_margins.constprop.0
> > drivers/video/fbdev/core/fbcon.c:1410
> > fbcon_switch
> > drivers/video/fbdev/core/fbcon.c:2261
> > redraw_screen
> > drivers/tty/vt/vt.c:994
> > fbcon_modechanged
> > drivers/video/fbdev/core/fbcon.c:2693
> > fbcon_update_vcs
> > drivers/video/fbdev/core/fbcon.c:2732
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Reported-by: <co+b0df61d49532b2ee@bugs.sh>
> > Suggested-by: Helge Deller <deller@gmx.de>
> > Assisted-by: LLM
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > Changes in v2:
> > - Limit virtual geometry and offsets to 8192 x 8192. This retains 8K mode
> > support while bounding all generic fbdev drawing calculations.
> > - Cap videomemorysize at 512 MiB.
> > - Keep the existing arithmetic types now that all inputs are bounded.
> >
> > drivers/video/fbdev/vfb.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
> > index de137b2bd..de40ba8c3 100644
> > --- a/drivers/video/fbdev/vfb.c
> > +++ b/drivers/video/fbdev/vfb.c
> > @@ -31,6 +31,9 @@
> > */
> >
> > #define VIDEOMEMSIZE (1*1024*1024) /* 1 MB */
> > +#define MAX_VIDEOMEMSIZE (512 * 1024 * 1024)
> > +#define MAX_XRES 8192
> > +#define MAX_YRES 8192
> >
> > static void *videomemory;
> > static u_long videomemorysize = VIDEOMEMSIZE;
> > @@ -159,6 +162,14 @@ static int vfb_check_var(struct fb_var_screeninfo *var,
> > else
> > return -EINVAL;
> >
> > + if (var->xres_virtual > MAX_XRES ||
> > + var->yres_virtual > MAX_YRES)
> > + return -EINVAL;
> > +
> > + if (var->xoffset > MAX_XRES - var->xres ||
> > + var->yoffset > MAX_YRES - var->yres)
> > + return -EINVAL;
>
> Instead of returning EINVAL, I wonder if we could simply
> cap the resolutions at MAX_XRES/MAX_YRES?
>
>
> > +
> > if (var->xres_virtual < var->xoffset + var->xres)
> > var->xres_virtual = var->xoffset + var->xres;
> > if (var->yres_virtual < var->yoffset + var->yres)
> > @@ -434,9 +445,13 @@ static int __init vfb_setup(char *options)
> > static int vfb_probe(struct platform_device *dev)
> > {
> > struct fb_info *info;
> > - unsigned int size = PAGE_ALIGN(videomemorysize);
> > + unsigned int size;
> > int retval = -ENOMEM;
> >
>
> and here maybe
> videomemorysize = min(videomemorysize, MAX_VIDEOMEMSIZE);
>
> that way the driver loads even if the provided too big value?
>
> Helge
> > + if (videomemorysize > MAX_VIDEOMEMSIZE)
> > + return -EINVAL;
> > + size = PAGE_ALIGN(videomemorysize);
>
>
Yes, that makes sense. I'll cap the geometry and videomemorysize as
suggested and send a v3.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-26 16:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-26 15:46 [PATCH v2] fbdev: vfb: Validate framebuffer geometry and memory size Weiming Shi
2026-10-26 16:06 ` Helge Deller
2026-10-26 16:26 ` Weiming Shi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®