kernel/linux.git/drivers/video, 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

fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2

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

[ Upstream commit bc87bb342f106a0402186bcb588fcbe945dced4b ] There are some actions with value 'tmp' but 'dst_addr' is checked instead. It is obvious that a copy-paste error was made here and the value of variable 'tmp' should be checked here. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Aleksandr Burakov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

backlight: lp8788: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit 392346827fbe8a7fd573dfb145170d7949f639a6 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: c5a51053cf3b ("backlight: add new lp8788 backlight driver") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-4-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: lm3639: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit abb5a5d951fbea3feb5c4ba179b89bb96a1d3462 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 0f59858d5119 ("backlight: add new lm3639 backlight driver") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-3-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: da9052: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit 0285e9efaee8276305db5c52a59baf84e9731556 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 6ede3d832aaa ("backlight: add driver for DA9052/53 PMIC v1") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-2-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: lm3630a: Don't set bl->props.brightness in get_brightness

2024-03-26T22:20:52+00:00

[ Upstream commit 4bf7ddd2d2f0f8826f25f74c7eba4e2c323a1446 ] There's no need to set bl->props.brightness, the get_brightness function is just supposed to return the current brightness and not touch the struct. With that done we can also remove the 'goto out' and just return the value. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Signed-off-by: Luca Weiss Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220-lm3630a-fixups-v1-2-9ca62f7e4a33@z3ntu.xyz Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: lm3630a: Initialize backlight_properties on init

2024-03-26T22:20:52+00:00

[ Upstream commit ad9aeb0e3aa90ebdad5fabf9c21783740eb95907 ] The backlight_properties struct should be initialized to zero before using, otherwise there will be some random values in the struct. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Signed-off-by: Luca Weiss Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220-lm3630a-fixups-v1-1-9ca62f7e4a33@z3ntu.xyz Signed-off-by: Lee Jones 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: sis: Error out if pixclock equals zero

2024-03-01T12:26:25+00:00

[ Upstream commit e421946be7d9bf545147bea8419ef8239cb7ca52 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. Signed-off-by: Fullway Wang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev: savage: Error out if pixclock equals zero

2024-03-01T12:26:25+00:00

[ Upstream commit 04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. Signed-off-by: Fullway Wang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin