Thread (6 messages) 6 messages, 5 authors, 2023-04-11

Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace

From: Daniel Vetter <hidden>
Date: 2023-04-11 14:25:43
Also in: dri-devel, intel-gfx, stable

On Tue, Apr 11, 2023 at 04:03:24PM +0200, Javier Martinez Canillas wrote:
Daniel Vetter [off-list ref] writes:
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")
[..]
quoted
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 875541ff185b..3fd95a79e4c3 100644
--- 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();
I don't have a better idea on how to fix this and as you said the whole
struct fb_var_screeninfo is an uAPI anyways...

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thanks for taking a look, merged to drm-misc-fixes.
-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help