Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2023-04-11 15:58:08
Also in:
dri-devel, intel-gfx, stable
Hi Daniel, On Tue, Apr 11, 2023 at 3:44 PM Daniel Vetter [off-list ref] wrote:
On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:quoted
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") - I failed to realize that nasty userspace could set this. It's not pretty to mix up kernel-internal and userspace uapi flags like this, but since the entire fb_var_screeninfo structure is uapi we'd need to either add a new parameter to the ->fb_set_par callback and fb_set_par() function, which has a _lot_ of users. Or some other fairly ugly side-channel int fb_info. Neither is a pretty prospect. Instead just correct the issue at hand by filtering out this kernel-internal flag in the ioctl handling code. Signed-off-by: Daniel Vetter <redacted> Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
An Ack on this (or a better idea) would be great, so I can stuff it into -fixes.
I don't understand what the original commit this fixes is doing anyway...
quoted
--- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOPUT_VSCREENINFO: if (copy_from_user(&var, argp, sizeof(var))) return -EFAULT; + /* only for kernel-internal use */ + var.activate &= ~FB_ACTIVATE_KD_TEXT; console_lock(); lock_fb_info(info); ret = fbcon_modechange_possible(info, &var);
Perhaps FB_ACTIVATE_KD_TEXT should be removed (marked as
reserved) from include/uapi/linux/fb.h, too?
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