kernel/linux.git/drivers/video/fbdev/core, branch v6.1.87

fbmon: prevent division by zero in fb_videomode_from_videomode()

2024-04-13T11:05:21+00:00

[ Upstream commit c2d953276b8b27459baed1277a4fdd5dd9bd4126 ] The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode(). Found by Linux Verification Center (linuxtesting.org) with Svace. Signed-off-by: Roman Smirnov Reviewed-by: Sergey Shtylyov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbcon: always restore the old font data in fbcon_do_set_font()

2024-03-06T14:45:09+00:00

[ Upstream commit 00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f ] Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.) Signed-off-by: Jiri Slaby (SUSE) Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") Reported-and-tested-by: Ubisectech Sirius Cc: Ubisectech Sirius Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20240208114411.14604-1-jirislaby@kernel.org Signed-off-by: Sasha Levin

fbdev: flush deferred IO before closing

2024-01-25T23:27:42+00:00

commit 33cd6ea9c0673517cdb06ad5c915c6f22e9615fc upstream. When framebuffer gets closed, the queued deferred IO gets cancelled. This can cause some last display data to vanish. This is problematic for users who send a still image to the framebuffer, then close the file: the image may never appear. To ensure none of display data get lost, flush the queued deferred IO first before closing. Another possible solution is to delete the cancel_delayed_work_sync() instead. The difference is that the display may appear some time after closing. However, the clearing of page mapping after this needs to be removed too, because the page mapping is used by the deferred work. It is not completely obvious whether it is okay to not clear the page mapping. For a patch intended for stable trees, go with the simple and obvious solution. Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

fbdev: flush deferred work in fb_deferred_io_fsync()

2024-01-25T23:27:42+00:00

commit 15e4c1f462279b4e128f27de48133e0debe9e0df upstream. The driver's fsync() is supposed to flush any pending operation to hardware. It is implemented in this driver by cancelling the queued deferred IO first, then schedule it for "immediate execution" by calling schedule_delayed_work() again with delay=0. However, setting delay=0 only means the work is scheduled immediately, it does not mean the work is executed immediately. There is no guarantee that the work is finished after schedule_delayed_work() returns. After this driver's fsync() returns, there can still be pending work. Furthermore, if close() is called by users immediately after fsync(), the pending work gets cancelled and fsync() may do nothing. To ensure that the deferred IO completes, use flush_delayed_work() instead. Write operations to this driver either write to the device directly, or invoke schedule_delayed_work(); so by flushing the workqueue, it can be guaranteed that all previous writes make it to the device. Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

fbdev: fix potential OOB read in fast_imageblit()

2023-07-01T11:16:25+00:00

commit c2d22806aecb24e2de55c30a06e5d6eb297d161d upstream. There is a potential OOB read at fast_imageblit, for "colortab[(*src >> 4)]" can become a negative value due to "const char *s = image->data, *src". This change makes sure the index for colortab always positive or zero. Similar commit: https://patchwork.kernel.org/patch/11746067 Potential bug report: https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ Signed-off-by: Zhang Shurong Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

fbcon: Fix null-ptr-deref in soft_cursor

2023-06-09T08:34:26+00:00

commit d78bd6cc68276bd57f766f7cb98bfe32c23ab327 upstream. syzbot repored this bug in the softcursor code: BUG: KASAN: null-ptr-deref in soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr 0000000000000200 by task kworker/u4:1/12 CPU: 0 PID: 12 Comm: kworker/u4:1 Not tainted 6.4.0-rc3-syzkaller-geb0f1697d729 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 Workqueue: events_power_efficient fb_flashcursor Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_report+0xe4/0x514 mm/kasan/report.c:465 kasan_report+0xd4/0x130 mm/kasan/report.c:572 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 __asan_memcpy+0x3c/0x84 mm/kasan/shadow.c:105 soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0x113c/0x1a64 drivers/video/fbdev/core/bitblit.c:377 fb_flashcursor+0x35c/0x54c drivers/video/fbdev/core/fbcon.c:380 process_one_work+0x788/0x12d4 kernel/workqueue.c:2405 worker_thread+0x8e0/0xfe8 kernel/workqueue.c:2552 kthread+0x288/0x310 kernel/kthread.c:379 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:853 This fix let bit_cursor() bail out early when a font bitmap isn't available yet. Signed-off-by: Helge Deller Reported-by: syzbot+d910bd780e6efac35869@syzkaller.appspotmail.com Acked-by: Sam Ravnborg Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

fbdev: modedb: Add 1920x1080 at 60 Hz video mode

2023-06-09T08:34:09+00:00

[ Upstream commit c8902258b2b8ecaa1b8d88c312853c5b14c2553d ] Add typical resolution for Full-HD monitors. Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbcon: set_con2fb_map needs to set con2fb_map!

2023-04-20T10:35:07+00:00

commit fffb0b52d5258554c645c966c6cbef7de50b851d upstream. I got really badly confused in d443d9386472 ("fbcon: move more common code into fb_open()") because we set the con2fb_map before the failure points, which didn't look good. But in trying to fix that I moved the assignment into the wrong path - we need to do it for _all_ vc we take over, not just the first one (which additionally requires the call to con2fb_acquire_newinfo). I've figured this out because of a KASAN bug report, where the fbcon_registered_fb and fbcon_display arrays went out of sync in fbcon_mode_deleted() because the con2fb_map pointed at the old fb_info, but the modes and everything was updated for the new one. Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Tested-by: Xingyuan Mo Fixes: d443d9386472 ("fbcon: move more common code into fb_open()") Reported-by: Xingyuan Mo Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Xingyuan Mo Cc: Thomas Zimmermann Cc: Helge Deller Cc: # v5.19+ Signed-off-by: Greg Kroah-Hartman

fbcon: Fix error paths in set_con2fb_map

2023-04-20T10:35:07+00:00

commit edf79dd2172233452ff142dcc98b19d955fc8974 upstream. This is a regressoin introduced in b07db3958485 ("fbcon: Ditch error handling for con2fb_release_oldinfo"). I failed to realize what the if (!err) checks. The mentioned commit was dropping the con2fb_release_oldinfo() return value but the if (!err) was also checking whether the con2fb_acquire_newinfo() function call above failed or not. Fix this with an early return statement. Note that there's still a difference compared to the orginal state of the code, the below lines are now also skipped on error: if (!search_fb_in_map(info_idx)) info_idx = newidx; These are only needed when we've actually thrown out an old fb_info from the console mappings, which only happens later on. Also move the fbcon_add_cursor_work() call into the same if block, it's all protected by console_lock so doesn't matter when we set up the blinking cursor delayed work anyway. This further simplifies the control flow and allows us to ditch the found local variable. v2: Clarify commit message (Javier) Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Tested-by: Xingyuan Mo Fixes: b07db3958485 ("fbcon: Ditch error handling for con2fb_release_oldinfo") Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Xingyuan Mo Cc: Thomas Zimmermann Cc: Helge Deller Cc: # v5.19+ Signed-off-by: Greg Kroah-Hartman

fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace

2023-04-20T10:35:06+00:00

commit 6fd33a3333c7916689b8f051a185defe4dd515b0 upstream. 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. Reviewed-by: Javier Martinez Canillas Acked-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") Cc: Alex Deucher Cc: shlomo@fastmail.com Cc: Michel Dänzer Cc: Noralf Trønnes Cc: Thomas Zimmermann Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.7+ Cc: Bartlomiej Zolnierkiewicz Cc: Geert Uytterhoeven Cc: Nathan Chancellor Cc: Qiujun Huang Cc: Peter Rosin Cc: linux-fbdev@vger.kernel.org Cc: Helge Deller Cc: Sam Ravnborg Cc: Geert Uytterhoeven Cc: Samuel Thibault Cc: Tetsuo Handa Cc: Shigeru Yoshida Link: https://patchwork.freedesktop.org/patch/msgid/20230404193934.472457-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman