linux-stable.git/drivers/video/console/fbcon.c, branch linux-4.4.y

tty: vt: always invoke vc->vc_sw->con_resize callback

2021-05-26T09:27:34+00:00

commit ffb324e6f874121f7dce5bdae5e05d02baae7269 upstream.

syzbot is reporting OOB write at vga16fb_imageblit() [1], for
resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether
requested rows/columns fit the amount of memory reserved for the graphical
screen if current mode is KD_GRAPHICS.

----------
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char *argv[])
  {
        const int fd = open("/dev/char/4:1", O_RDWR);
        struct vt_sizes vt = { 0x4100, 2 };

        ioctl(fd, KDSETMODE, KD_GRAPHICS);
        ioctl(fd, VT_RESIZE, &vt);
        ioctl(fd, KDSETMODE, KD_TEXT);
        return 0;
  }
----------

Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode !=
KD_GRAPHICS check from resize_screen() to fbcon_resize().

Link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 [1]
Reported-by: syzbot 
Suggested-by: Linus Torvalds 
Signed-off-by: Tetsuo Handa 
Tested-by: syzbot 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fbcon: Fix global-out-of-bounds read in fbcon_get_font()

2020-10-14T07:46:21+00:00

commit 5af08640795b2b9a940c9266c0260455377ae262 upstream.

fbcon_get_font() is reading out-of-bounds. A malicious user may resize
`vc->vc_font.height` to a large value, causing fbcon_get_font() to
read out of `fontdata`.

fbcon_get_font() handles both built-in and user-provided fonts.
Fortunately, recently we have added FONT_EXTRA_WORDS support for built-in
fonts, so fix it by adding range checks using FNTSIZE().

This patch depends on patch "fbdev, newport_con: Move FONT_EXTRA_WORDS
macros into linux/font.h", and patch "Fonts: Support FONT_EXTRA_WORDS
macros for built-in fonts".

Cc: stable@vger.kernel.org
Reported-and-tested-by: syzbot+29d4ed7f3bdedf2aa2fd@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
Signed-off-by: Peilin Ye 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/b34544687a1a09d6de630659eb7a773f4953238b.1600953813.git.yepeilin.cs@gmail.com
Signed-off-by: Greg Kroah-Hartman

fbcon: Fix user font detection test at fbcon_resize().

2020-09-23T06:44:27+00:00

[ Upstream commit ec0972adecb391a8d8650832263a4790f3bfb4df ]

syzbot is reporting OOB read at fbcon_resize() [1], for
commit 39b3cffb8cf31117 ("fbcon: prevent user font height or width change
 from causing potential out-of-bounds access") is by error using
registered_fb[con2fb_map[vc->vc_num]]->fbcon_par->p->userfont (which was
set to non-zero) instead of fb_display[vc->vc_num].userfont (which remains
zero for that display).

We could remove tricky userfont flag [2], for we can determine it by
comparing address of the font data and addresses of built-in font data.
But since that commit is failing to fix the original OOB read [3], this
patch keeps the change minimal in case we decide to revert altogether.

[1] https://syzkaller.appspot.com/bug?id=ebcbbb6576958a496500fee9cf7aa83ea00b5920
[2] https://syzkaller.appspot.com/text?tag=Patch&x=14030853900000
[3] https://syzkaller.appspot.com/bug?id=6fba8c186d97cf1011ab17660e633b1cc4e080c9

Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Fixes: 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access")
Cc: George Kennedy 
Link: https://lore.kernel.org/r/f6e3e611-8704-1263-d163-f52c906a4f06@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

fbcon: remove now unusued 'softback_lines' cursor() argument

2020-09-23T06:44:25+00:00

commit 06a0df4d1b8b13b551668e47b11fd7629033b7df upstream.

Since the softscroll code got removed, this argument is always zero and
makes no sense any more.

Tested-by: Yuan Ming 
Tested-by: Willy Tarreau 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fbcon: remove soft scrollback code

2020-09-23T06:44:25+00:00

commit 50145474f6ef4a9c19205b173da6264a644c7489 upstream.

This (and the VGA soft scrollback) turns out to have various nasty small
special cases that nobody really is willing to fight.  The soft
scrollback code was really useful a few decades ago when you typically
used the console interactively as the main way to interact with the
machine, but that just isn't the case any more.

So it's not worth dragging along.

Tested-by: Yuan Ming 
Tested-by: Willy Tarreau 
Acked-by: Bartlomiej Zolnierkiewicz 
Acked-by: Daniel Vetter 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fbcon: prevent user font height or width change from causing potential out-of-bounds access

2020-09-03T09:19:26+00:00

commit 39b3cffb8cf3111738ea993e2757ab382253d86a upstream.

Add a check to fbcon_resize() to ensure that a possible change to user font
height or user font width will not allow a font data out-of-bounds access.
NOTE: must use original charcount in calculation as font charcount can
change and cannot be used to determine the font data allocated size.

Signed-off-by: George Kennedy 
Cc: stable 
Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/1596213192-6635-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman

fbdev: fbcon: Fix unregister crash when more than one framebuffer

2019-02-20T09:13:12+00:00

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] (show_stack+0x20/0x24)
[   76.479022]  r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81
[   76.479060] [] (show_stack) from [] (dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] (warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] (__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] (queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00
[   76.479298]  r4:20000113
[   76.479348] [] (queue_work_on) from [] (cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] (call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] (expire_timers+0x10c/0x12c)
[   76.479495]  r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] (run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] (__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] (irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0
[   76.479734]  r4:00000000
[   76.479764] [] (irq_exit) from [] (__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] (bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] (__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

fbcon: Fix vc attr at deinit

2017-03-30T07:35:20+00:00

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

fbcon: set a default value to blink interval

2016-03-09T23:34:50+00:00

commit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream.

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
	fbcon: use the cursor blink interval provided by vt

two attempts have been made at fixing a possible hang caused by
cursor_timer_handler. That function registers a timer to be triggered at
"jiffies + fbcon_ops.cur_blink_jiffies".

A new case had been encountered during initialisation of clcd-pl11x:

    fbcon_fb_registered
    do_fbcon_takeover

    ->  do_register_con_driver
        fbcon_startup
    (A) add_cursor_timer (with cur_blink_jiffies = 0)

    ->  do_bind_con_driver
        visual_init
        fbcon_init
    (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);

If we take an softirq anywhere between A and B (and we do),
cursor_timer_handler executes indefinitely.

Instead of patching all possible paths that lead to this case one at a
time, fix the issue at the source and initialise cur_blink_jiffies to
200ms when allocating fbcon_ops. This was its default value before
aforesaid commit. fbcon_cursor or fbcon_init will refine this value
downstream.

Signed-off-by: Jean-Philippe Brucker 
Tested-by: Scot Doyle 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

fbcon: initialize blink interval before calling fb_set_par

2015-10-18T05:00:39+00:00

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
    fbcon: use the cursor blink interval provided by vt

a PPC64LE kernel fails to boot when fbcon_add_cursor_timer uses an
uninitialized ops->cur_blink_jiffies. Prevent by initializing
in fbcon_init before the call to info->fbops->fb_set_par.

Reported-and-tested-by: Alistair Popple 
Signed-off-by: Scot Doyle 
Cc:  [v4.2]
Signed-off-by: Greg Kroah-Hartman