From 2be358790e15c34668f3694d4c3d1f2c5f29a709 Mon Sep 17 00:00:00 2001 From: Bartosz Golaszewski Date: Tue, 8 Apr 2025 09:42:56 +0200 Subject: fbdev: via: use new GPIO line value setter callbacks struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Signed-off-by: Helge Deller --- drivers/video/fbdev/via/via-gpio.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/via/via-gpio.c b/drivers/video/fbdev/via/via-gpio.c index 9577c2cd52c7..27226a8f3f42 100644 --- a/drivers/video/fbdev/via/via-gpio.c +++ b/drivers/video/fbdev/via/via-gpio.c @@ -81,8 +81,7 @@ struct viafb_gpio_cfg { /* * GPIO access functions */ -static void via_gpio_set(struct gpio_chip *chip, unsigned int nr, - int value) +static int via_gpio_set(struct gpio_chip *chip, unsigned int nr, int value) { struct viafb_gpio_cfg *cfg = gpiochip_get_data(chip); u8 reg; @@ -99,13 +98,14 @@ static void via_gpio_set(struct gpio_chip *chip, unsigned int nr, reg &= ~(0x10 << gpio->vg_mask_shift); via_write_reg(VIASR, gpio->vg_port_index, reg); spin_unlock_irqrestore(&cfg->vdev->reg_lock, flags); + + return 0; } static int via_gpio_dir_out(struct gpio_chip *chip, unsigned int nr, int value) { - via_gpio_set(chip, nr, value); - return 0; + return via_gpio_set(chip, nr, value); } /* @@ -146,7 +146,7 @@ static struct viafb_gpio_cfg viafb_gpio_config = { .label = "VIAFB onboard GPIO", .owner = THIS_MODULE, .direction_output = via_gpio_dir_out, - .set = via_gpio_set, + .set_rv = via_gpio_set, .direction_input = via_gpio_dir_input, .get = via_gpio_get, .base = -1, -- cgit From 67ebb5890a15e82f369df46e9411250252b5a98c Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Fri, 18 Apr 2025 13:51:35 +0100 Subject: fbdev: carminefb: Fix spelling mistake of CARMINE_TOTAL_DIPLAY_MEM There is a spelling mistake in macro CARMINE_TOTAL_DIPLAY_MEM. Fix it. Signed-off-by: Colin Ian King Signed-off-by: Helge Deller --- drivers/video/fbdev/carminefb.c | 8 ++++---- drivers/video/fbdev/carminefb.h | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/carminefb.c b/drivers/video/fbdev/carminefb.c index e56065cdba97..2bdd67595891 100644 --- a/drivers/video/fbdev/carminefb.c +++ b/drivers/video/fbdev/carminefb.c @@ -649,13 +649,13 @@ static int carminefb_probe(struct pci_dev *dev, const struct pci_device_id *ent) * is required for that largest resolution to avoid remaps at run * time */ - if (carminefb_fix.smem_len > CARMINE_TOTAL_DIPLAY_MEM) - carminefb_fix.smem_len = CARMINE_TOTAL_DIPLAY_MEM; + if (carminefb_fix.smem_len > CARMINE_TOTAL_DISPLAY_MEM) + carminefb_fix.smem_len = CARMINE_TOTAL_DISPLAY_MEM; - else if (carminefb_fix.smem_len < CARMINE_TOTAL_DIPLAY_MEM) { + else if (carminefb_fix.smem_len < CARMINE_TOTAL_DISPLAY_MEM) { printk(KERN_ERR "carminefb: Memory bar is only %d bytes, %d " "are required.", carminefb_fix.smem_len, - CARMINE_TOTAL_DIPLAY_MEM); + CARMINE_TOTAL_DISPLAY_MEM); goto err_unmap_vregs; } diff --git a/drivers/video/fbdev/carminefb.h b/drivers/video/fbdev/carminefb.h index 297688eba469..c9825481d96b 100644 --- a/drivers/video/fbdev/carminefb.h +++ b/drivers/video/fbdev/carminefb.h @@ -7,7 +7,7 @@ #define MAX_DISPLAY 2 #define CARMINE_DISPLAY_MEM (800 * 600 * 4) -#define CARMINE_TOTAL_DIPLAY_MEM (CARMINE_DISPLAY_MEM * MAX_DISPLAY) +#define CARMINE_TOTAL_DISPLAY_MEM (CARMINE_DISPLAY_MEM * MAX_DISPLAY) #define CARMINE_USE_DISPLAY0 (1 << 0) #define CARMINE_USE_DISPLAY1 (1 << 1) -- cgit From c9b26429c8c7aa2836322aeab38be4254d166e02 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 24 Apr 2025 14:56:52 +0300 Subject: fbdev: atyfb: Remove unused PCI vendor ID The custom definition of PCI vendor ID in video/mach64.h is unused. Remove it. Note, that the proper one is available in pci_ids.h. Signed-off-by: Andy Shevchenko Signed-off-by: Helge Deller --- include/video/mach64.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/video/mach64.h b/include/video/mach64.h index d96e3c189634..f1709f7c8421 100644 --- a/include/video/mach64.h +++ b/include/video/mach64.h @@ -934,9 +934,6 @@ #define MEM_BNDRY_EN 0x00040000 #define ONE_MB 0x100000 -/* ATI PCI constants */ -#define PCI_ATI_VENDOR_ID 0x1002 - /* CNFG_CHIP_ID register constants */ #define CFG_CHIP_TYPE 0x0000FFFF -- cgit From 34fe05cd2d0f4cc625afb656469a9838f02ca59e Mon Sep 17 00:00:00 2001 From: Zijun Hu Date: Mon, 7 Apr 2025 19:55:20 +0800 Subject: fbdev: nvidiafb: Correct const string length in nvidiafb_setup() The actual length of const string "noaccel" is 7, but the strncmp() branch in nvidiafb_setup() wrongly hard codes it as 6. Fix by using actual length 7 as argument of the strncmp(). Signed-off-by: Zijun Hu Signed-off-by: Helge Deller --- drivers/video/fbdev/nvidia/nvidia.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/nvidia/nvidia.c b/drivers/video/fbdev/nvidia/nvidia.c index 8900f181f195..cfaf9454014d 100644 --- a/drivers/video/fbdev/nvidia/nvidia.c +++ b/drivers/video/fbdev/nvidia/nvidia.c @@ -1484,7 +1484,7 @@ static int nvidiafb_setup(char *options) flatpanel = 1; } else if (!strncmp(this_opt, "hwcur", 5)) { hwcur = 1; - } else if (!strncmp(this_opt, "noaccel", 6)) { + } else if (!strncmp(this_opt, "noaccel", 7)) { noaccel = 1; } else if (!strncmp(this_opt, "noscale", 7)) { noscale = 1; -- cgit From ede481f6dad47d40b7e561cfbc6c04286a9faf1a Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 25 Apr 2025 23:23:06 -0700 Subject: fbdev: arkfb: Cast ics5342_init() allocation type In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct dac_info *" but the returned type will be "struct ics5342_info *", which has a larger allocation size. This is by design, as struct ics5342_info contains struct dac_info as its first member. (patch slightly modified by Helge Deller) Signed-off-by: Kees Cook Signed-off-by: Helge Deller --- drivers/video/fbdev/arkfb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c index 082501feceb9..ec084323115f 100644 --- a/drivers/video/fbdev/arkfb.c +++ b/drivers/video/fbdev/arkfb.c @@ -431,9 +431,10 @@ static struct dac_ops ics5342_ops = { static struct dac_info * ics5342_init(dac_read_regs_t drr, dac_write_regs_t dwr, void *data) { - struct dac_info *info = kzalloc(sizeof(struct ics5342_info), GFP_KERNEL); + struct ics5342_info *ics_info = kzalloc(sizeof(struct ics5342_info), GFP_KERNEL); + struct dac_info *info = &ics_info->dac; - if (! info) + if (!ics_info) return NULL; info->dacops = &ics5342_ops; -- cgit From 864f9963ec6b4b76d104d595ba28110b87158003 Mon Sep 17 00:00:00 2001 From: GONG Ruiqi Date: Sun, 27 Apr 2025 10:53:03 +0800 Subject: vgacon: Add check for vc_origin address range in vgacon_scroll() Our in-house Syzkaller reported the following BUG (twice), which we believed was the same issue with [1]: ================================================================== BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The buggy address belongs to the object at ffff88800f5be000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 2656 bytes to the right of allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500) ... Memory state around the buggy address: ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== By analyzing the vmcore, we found that vc->vc_origin was somehow placed one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and further writings to /dev/vcs caused out-of-bounds reads (and writes right after) in vcs_write_buf_noattr(). Our further experiments show that in most cases, vc->vc_origin equals to vga_vram_base when the console is in KD_TEXT mode, and it's around vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around vc->vc_screenbuf while the console is in KD_TEXT mode, and then by writing the special 'ESC M' control sequence to the tty certain times (depends on the value of `vc->state.y - vc->vc_top`), we can eventually move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on QEMU: ``` int main() { const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top` int tty_fd, vcs_fd; const char *tty_path = "/dev/tty0"; const char *vcs_path = "/dev/vcs"; const char escape_seq[] = "\x1bM"; // ESC + M const char trigger_seq[] = "Let's trigger an OOB write."; struct vt_sizes vt_size = { 70, 2 }; int blank = TIOCL_BLANKSCREEN; tty_fd = open(tty_path, O_RDWR); char vesa_mode[] = { TIOCL_SETVESABLANK, 1 }; ioctl(tty_fd, TIOCLINUX, vesa_mode); ioctl(tty_fd, TIOCLINUX, &blank); ioctl(tty_fd, VT_RESIZE, &vt_size); for (int i = 0; i < RI_NUM; ++i) write(tty_fd, escape_seq, sizeof(escape_seq) - 1); vcs_fd = open(vcs_path, O_RDWR); write(vcs_fd, trigger_seq, sizeof(trigger_seq)); close(vcs_fd); close(tty_fd); return 0; } ``` To solve this problem, add an address range validation check in vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf. Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Yi Yang Signed-off-by: Yi Yang Signed-off-by: GONG Ruiqi Signed-off-by: Helge Deller --- drivers/video/console/vgacon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c index 37bd18730fe0..f9cdbf8c53e3 100644 --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -1168,7 +1168,7 @@ static bool vgacon_scroll(struct vc_data *c, unsigned int t, unsigned int b, c->vc_screenbuf_size - delta); c->vc_origin = vga_vram_end - c->vc_screenbuf_size; vga_rolled_over = 0; - } else + } else if (oldo - delta >= (unsigned long)c->vc_screenbuf) c->vc_origin -= delta; c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size; scr_memsetw((u16 *) (c->vc_origin), c->vc_video_erase_char, -- cgit From cedc1b63394a866bf8663a3e40f4546f1d28c8d8 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 9 May 2025 13:06:47 -0700 Subject: fbcon: Make sure modelist not set on unregistered console It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Reported-by: syzbot+a7d4444e7b6e743572f7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/ Signed-off-by: Kees Cook Signed-off-by: Helge Deller --- drivers/video/fbdev/core/fbcon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index ac3c99ed92d1..2df48037688d 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -117,9 +117,14 @@ static signed char con2fb_map_boot[MAX_NR_CONSOLES]; static struct fb_info *fbcon_info_from_console(int console) { + signed char fb; WARN_CONSOLE_UNLOCKED(); - return fbcon_registered_fb[con2fb_map[console]]; + fb = con2fb_map[console]; + if (fb < 0 || fb >= ARRAY_SIZE(fbcon_registered_fb)) + return NULL; + + return fbcon_registered_fb[fb]; } static int logo_lines; -- cgit From 3f6dae09fc8c306eb70fdfef70726e1f154e173a Mon Sep 17 00:00:00 2001 From: Sergey Shtylyov Date: Wed, 14 May 2025 23:35:58 +0300 Subject: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 96fe6a2109db ("[PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support") Signed-off-by: Sergey Shtylyov Signed-off-by: Helge Deller --- drivers/video/fbdev/core/fbcvt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcvt.c b/drivers/video/fbdev/core/fbcvt.c index 64843464c661..cd3821bd82e5 100644 --- a/drivers/video/fbdev/core/fbcvt.c +++ b/drivers/video/fbdev/core/fbcvt.c @@ -312,7 +312,7 @@ int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb) cvt.f_refresh = cvt.refresh; cvt.interlace = 1; - if (!cvt.xres || !cvt.yres || !cvt.refresh) { + if (!cvt.xres || !cvt.yres || !cvt.refresh || cvt.f_refresh > INT_MAX) { printk(KERN_INFO "fbcvt: Invalid input parameters\n"); return 1; } -- cgit From 9c221db509695243f37fd68e5313a4c62eac9887 Mon Sep 17 00:00:00 2001 From: Rujra Bhatt Date: Mon, 19 May 2025 20:08:32 +0530 Subject: fbdev: sstfb.rst: Fix spelling mistake Fix spelling: "tweeks" to "tweaks" Signed-off-by: Rujra Bhatt Signed-off-by: Helge Deller --- Documentation/fb/sstfb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst index 88d5a52b13d8..7386eb63bac8 100644 --- a/Documentation/fb/sstfb.rst +++ b/Documentation/fb/sstfb.rst @@ -192,7 +192,7 @@ Todo - Get rid of the previous paragraph. - Buy more coffee. - test/port to other arch. -- try to add panning using tweeks with front and back buffer . +- try to add panning using tweaks with front and back buffer. - try to implement accel on voodoo2, this board can actually do a lot in 2D even if it was sold as a 3D only board ... -- cgit From 17186f1f90d34fa701e4f14e6818305151637b9e Mon Sep 17 00:00:00 2001 From: Murad Masimov Date: Mon, 28 Apr 2025 18:34:06 +0300 Subject: fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - "This should not happen" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Helge Deller --- drivers/video/fbdev/core/fbmem.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 3c568cff2913..e1557d80768f 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -388,7 +388,7 @@ static int fb_check_foreignness(struct fb_info *fi) static int do_register_framebuffer(struct fb_info *fb_info) { - int i; + int i, err = 0; struct fb_videomode mode; if (fb_check_foreignness(fb_info)) @@ -397,10 +397,18 @@ static int do_register_framebuffer(struct fb_info *fb_info) if (num_registered_fb == FB_MAX) return -ENXIO; - num_registered_fb++; for (i = 0 ; i < FB_MAX; i++) if (!registered_fb[i]) break; + + if (!fb_info->modelist.prev || !fb_info->modelist.next) + INIT_LIST_HEAD(&fb_info->modelist); + + fb_var_to_videomode(&mode, &fb_info->var); + err = fb_add_videomode(&mode, &fb_info->modelist); + if (err < 0) + return err; + fb_info->node = i; refcount_set(&fb_info->count, 1); mutex_init(&fb_info->lock); @@ -426,16 +434,12 @@ static int do_register_framebuffer(struct fb_info *fb_info) if (bitmap_empty(fb_info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT)) bitmap_fill(fb_info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT); - if (!fb_info->modelist.prev || !fb_info->modelist.next) - INIT_LIST_HEAD(&fb_info->modelist); - if (fb_info->skip_vt_switch) pm_vt_switch_required(fb_info->device, false); else pm_vt_switch_required(fb_info->device, true); - fb_var_to_videomode(&mode, &fb_info->var); - fb_add_videomode(&mode, &fb_info->modelist); + num_registered_fb++; registered_fb[i] = fb_info; #ifdef CONFIG_GUMSTIX_AM200EPD -- cgit From 05f6e183879d9785a3cdf2f08a498bc31b7a20aa Mon Sep 17 00:00:00 2001 From: Murad Masimov Date: Mon, 28 Apr 2025 18:34:07 +0300 Subject: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov Signed-off-by: Helge Deller --- drivers/video/fbdev/core/fbmem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index e1557d80768f..eca2498f2436 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -328,8 +328,10 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var) !list_empty(&info->modelist)) ret = fb_add_videomode(&mode, &info->modelist); - if (ret) + if (ret) { + info->var = old_var; return ret; + } event.info = info; event.data = &mode; -- cgit