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

fbcon: Fix a NULL pointer dereference issue in fbcon_putcs

2024-10-17T13:22:17+00:00

[ Upstream commit 5b97eebcce1b4f3f07a71f635d6aa3af96c236e7 ] syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, ¶m); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs. Reported-by: syzbot+3d613ae53c031502687a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d613ae53c031502687a Tested-by: syzbot+3d613ae53c031502687a@syzkaller.appspotmail.com Signed-off-by: Qianqiang Liu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev: fix incorrect address computation in deferred IO

2024-05-02T14:29:30+00:00

commit 78d9161d2bcd442d93d917339297ffa057dbee8c upstream. With deferred IO enabled, a page fault happens when data is written to the framebuffer device. Then driver determines which page is being updated by calculating the offset of the written virtual address within the virtual memory area, and uses this offset to get the updated page within the internal buffer. This page is later copied to hardware (thus the name "deferred IO"). This offset calculation is only correct if the virtual memory area is mapped to the beginning of the internal buffer. Otherwise this is wrong. For example, if users do: mmap(ptr, 4096, PROT_WRITE, MAP_FIXED | MAP_SHARED, fd, 0xff000); Then the virtual memory area will mapped at offset 0xff000 within the internal buffer. This offset 0xff000 is not accounted for, and wrong page is updated. Correct the calculation by using vmf->pgoff instead. With this change, the variable "offset" will no longer hold the exact offset value, but it is rounded down to multiples of PAGE_SIZE. But this is still correct, because this variable is only used to calculate the page offset. Reported-by: Harshit Mogalapalli Closes: https://lore.kernel.org/linux-fbdev/271372d6-e665-4e7f-b088-dee5f4ab341a@oracle.com Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: Signed-off-by: Nam Cao Reviewed-by: Thomas Zimmermann Tested-by: Harshit Mogalapalli Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20240423115053.4490-1-namcao@linutronix.de Signed-off-by: Greg Kroah-Hartman

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