linux-stable.git/drivers/video/fbdev/core/fbmem.c, branch linux-4.9.y

fbmem: don't allow too huge resolutions

2021-09-22T09:43:02+00:00

commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream.

syzbot is reporting page fault at vga16fb_fillrect() [1], for
vga16fb_check_var() is failing to detect multiplication overflow.

  if (vxres * vyres > maxmem) {
    vyres = maxmem / vxres;
    if (vyres < yres)
      return -ENOMEM;
  }

Since no module would accept too huge resolutions where multiplication
overflow happens, let's reject in the common path.

Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot 
Debugged-by: Randy Dunlap 
Signed-off-by: Tetsuo Handa 
Reviewed-by: Geert Uytterhoeven 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
Signed-off-by: Greg Kroah-Hartman

fbmem: add margin check to fb_check_caps()

2021-09-03T07:44:40+00:00

commit a49145acfb975d921464b84fe00279f99827d816 upstream.

A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
or yres setting in struct fb_var_screeninfo will result in a
KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
the margins are being cleared. The margins are cleared in
chunks and if the xres setting or yres setting is a value of
zero upto the chunk size, the failure will occur.

Add a margin check to validate xres and yres settings.

Signed-off-by: George Kennedy 
Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com
Reviewed-by: Dan Carpenter 
Cc: Dhaval Giani 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman

fbdev: potential information leak in do_fb_ioctl()

2020-04-24T05:59:14+00:00

commit d3d19d6fc5736a798b118971935ce274f7deaa82 upstream.

The "fix" struct has a 2 byte hole after ->ywrapstep and the
"fix = info->fix;" assignment doesn't necessarily clear it.  It depends
on the compiler.  The solution is just to replace the assignment with an
memcpy().

Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held")
Signed-off-by: Dan Carpenter 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Cc: Andrea Righi 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Daniel Thompson 
Cc: Peter Rosin 
Cc: Jani Nikula 
Cc: Gerd Hoffmann 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20200113100132.ixpaymordi24n3av@kili.mountain
Signed-off-by: Greg Kroah-Hartman

fbdev: fbmem: fix memory access if logo is bigger than the screen

2019-04-05T20:29:12+00:00

[ Upstream commit a5399db139cb3ad9b8502d8b1bd02da9ce0b9df0 ]

There is no clipping on the x or y axis for logos larger that the framebuffer
size. Therefore: a logo bigger than screen size leads to invalid memory access:

[    1.254664] Backtrace:
[    1.254728] [] (cfb_imageblit) from [] (fb_show_logo+0x620/0x684)
[    1.254763]  r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4
[    1.254774]  r4:c6a3e800
[    1.254810] [] (fb_show_logo) from [] (fbcon_switch+0x3fc/0x46c)
[    1.254842]  r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800
[    1.254852]  r4:c6808c00
[    1.254889] [] (fbcon_switch) from [] (redraw_screen+0xf0/0x1e8)
[    1.254918]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080
[    1.254928]  r4:c6808c00
[    1.254961] [] (redraw_screen) from [] (do_bind_con_driver+0x194/0x2e4)
[    1.254991]  r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0

So prevent displaying a logo bigger than screen size and avoid invalid
memory access.

Signed-off-by: Manfred Schlaegl 
Signed-off-by: Martin Kepplinger 
Cc: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

fbdev: fbmem: behave better with small rotated displays and many CPUs

2019-02-12T18:44:56+00:00

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

fb: fix lost console when the user unplugs a USB adapter

2018-09-09T18:01:25+00:00

commit 8c5b044299951acd91e830a688dd920477ea1eda upstream.

I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.

The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.

This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.

Signed-off-by: Mikulas Patocka 
Cc: Dave Airlie 
Cc: Bernie Thompson 
Cc: Ladislav Michl 
Cc: stable@vger.kernel.org
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

fbdev: fbmem: implement error handling in fbmem_init()

2016-05-10T08:58:29+00:00

fbmem_init() ignores all errors, while fbmem_exit() does not
check if deallocating resources are valid.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Tomi Valkeinen

fbdev: Debug knob to register without holding console_lock

2015-12-15T13:41:24+00:00

When the usual fbcon legacy options are enabled we have
->register_framebuffer
  ->fb notifier chain calls into fbcon
    ->fbcon sets up console on new fbi
      ->fbi->set_par
        ->drm_fb_helper_set_par exercises full kms api

And because of locking inversion hilarity all of register_framebuffer
is done with the console lock held. Which means that the first time on
driver load we exercise _all_ the kms code (all probe paths and
modeset paths for everything connected) is under the console lock.
That means if anything goes belly-up in that big pile of code nothing
ever reaches logfiles (and the machine is dead).

Usual tactic to debug that is to temporarily remove those console_lock
calls to be able to capture backtraces. I'm fed up writing this patch
and recompiling kernels. Hence this patch here to add an unsafe,
kernel-taining option to do this at runtime.

Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter 
Signed-off-by: Tomi Valkeinen

video/fbdev: Always built-in video= cmdline parsing

2014-08-06T12:50:02+00:00

In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.

But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.

Whiel at it fix the checkpatch fail in this code.

v2: Also move fb_mode_option. Spotted by the kbuild.

v3: Review from Geert:
- Keep the old copyright notice from fb_mem.c, although I have no
idea what exactly applies.
- Only compile this when needed.

Cc: Geert Uytterhoeven 
Cc: Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter 

--

I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel

fbdev: fbmem: remove positive test on unsigned values

2014-05-09T09:55:49+00:00

fb_image.dx, fb_image.dy and fbconf2bmap.framebuffer are __u32

Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
Signed-off-by: Tomi Valkeinen