- Jan 11, 2022
-
-
Alex Deucher authored
commit 9a45ac23 upstream. Add a function for drivers to check if the a firmware initialized fb is corresponds to their aperture. This allows drivers to check if the device corresponds to what the firmware set up as the display device. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- Nov 25, 2021
-
-
Javier Martinez Canillas authored
commit fb561bf9 upstream. The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the display hardware is already present. This is more likely to occur after commit d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") since the "efi-framebuffer" and "simple-framebuffer" platform devices are registered at a later time. Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/ Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:
-
- Nov 18, 2021
-
-
Christophe Leroy authored
[ Upstream commit f2719b26 ] While investigating a lockup at startup on Powerbook 3400C, it was identified that the fbdev driver generates alignment exception at startup: --- interrupt: 600 at memset+0x60/0xc0 NIP: c0021414 LR: c03fc49c CTR: 00007fff REGS: ca021c10 TRAP: 0600 Tainted: G W (5.14.2-pmac-00727-g12a41fa69492) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44008442 XER: 20000100 DAR: cab80020 DSISR: 00017c07 GPR00: 00000007 ca021cd0 c14412e0 cab80000 00000000 00100000 cab8001c 00000004 GPR08: 00100000 00007fff 00000000 00000000 84008442 00000000 c0006fb4 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00100000 GPR24: 00000000 81800000 00000320 c15fa400 c14d1878 00000000 c14d1800 c094e19c NIP [c0021414] memset+0x60/0xc0 LR [c03fc49c] chipsfb_pci_init+0x160/0x580 --- interrupt: 600 [ca021cd0] [c03fc46c] chipsfb_pci_init+0x130/0x580 (unreliable) [ca021d20] [c03a3a70] pci_device_probe+0xf8/0x1b8 [ca021d50] [c043d584] really_probe.part.0+0xac/0x388 [ca021d70] [c043d914] __driver_probe_device+0xb4/0x170 [ca021d90] [c043da18] driver_probe_device+0x48/0x144 [ca021dc0] [c043e318] __driver_attach+0x11c/0x1c4 [ca021de0] [c043ad30] bus_for_each_dev+0x88/0xf0 [ca021e10] [c043c724] bus_add_driver+0x190/0x22c [ca021e40] [c043ee94] driver_register+0x9c/0x170 [ca021e60] [c0006c28] do_one_initcall+0x54/0x1ec [ca021ed0] [c08246e4] kernel_init_freeable+0x1c0/0x270 [ca021f10] [c0006fdc] kernel_init+0x28/0x11c [ca021f30] [c0017148] ret_from_kernel_thread+0x14/0x1c Instruction dump: 7d4601a4 39490777 7d4701a4 39490888 7d4801a4 39490999 7d4901a4 39290aaa 7d2a01a4 4c00012c 4bfffe88 0fe00000 <4bfffe80> 9421fff0 38210010 48001970 This is due to 'dcbz' instruction being used on non-cached memory. 'dcbz' instruction is used by memset() to zeroize a complete cacheline at once, and memset() is not expected to be used on non cached memory. When performing a 'sparse' check on fbdev driver, it also appears that the use of memset() is unexpected: drivers/video/fbdev/chipsfb.c:334:17: warning: incorrect type in argument 1 (different address spaces) drivers/video/fbdev/chipsfb.c:334:17: expected void * drivers/video/fbdev/chipsfb.c:334:17: got char [noderef] __iomem *screen_base drivers/video/fbdev/chipsfb.c:334:15: warning: memset with byte count of 1048576 Use fb_memset() instead of memset(). fb_memset() is defined as memset_io() for powerpc. Fixes: 8c870933 ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK") Reported-by:
-
Imre Deak authored
[ Upstream commit 55285e21 ] Atm the EFI FB platform driver gets a runtime PM reference for the associated GFX PCI device during probing the EFI FB platform device and releases it only when the platform device gets unbound. When fbcon switches to the FB provided by the PCI device's driver (for instance i915/drmfb), the EFI FB will get only unregistered without the EFI FB platform device getting unbound, keeping the runtime PM reference acquired during the platform device probing. This reference will prevent the PCI driver from runtime suspending the device. Fix this by releasing the RPM reference from the EFI FB's destroy hook, called when the FB gets unregistered. While at it assert that pm_runtime_get_sync() didn't fail. v2: - Move pm_runtime_get_sync() before register_framebuffer() to avoid its race wrt. efifb_destroy()->pm_runtime_put(). (Daniel) - Assert that pm_runtime_get_sync() didn't fail. - Clarify commit message wrt. platform/PCI device/driver and driver removal vs. device unbinding. Fixes: a6c0fd3d ("efifb: Ensure graphics device for efifb stays at PCI D0") Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Acked-by:
-
- Oct 06, 2021
-
-
Mark Brown authored
The gbefb driver not only registers a driver but also the device for that driver. This is all well and good when run on the IP32 machines that are supported by the driver but since the driver supports building with COMPILE_TEST we might also be building on other platforms which do not have this hardware and will crash instantiating the driver. Add an IS_ENABLED() check so we compile out the device registration if we don't have the Kconfig option for the machine enabled. Fixes: 552ccf6b ("video: fbdev: gbefb: add COMPILE_TEST support") Signed-off-by:
-
Arnd Bergmann authored
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This can however result in a build failure when cfb_fillrect() etc are then also in loadable modules: x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x1f8): undefined reference to `cfb_fillrect' x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x200): undefined reference to `cfb_copyarea' x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x208): undefined reference to `cfb_imageblit' To work around this, change FB_SIMPLE to be a 'tristate' symbol, which still allows both to be =m together, but not one of them to be =y if the other one is =m. If a distro kernel picks this configuration, it can be determined by local policy which of the two modules gets loaded. The 'of_chosen' export is needed as this is the first loadable module referencing it. Alternatively, the Kconfig dependency could be changed to 'depends on DRM_SIMPLEDRM=n', which would forbid the configuration with both drivers. Fixes: 11e8f5fd ("drm: Add simpledrm driver") Acked-by: Rob Herring <robh@kernel.org> # for drivers/of/ Link: https://lore.kernel.org/all/20210721151839.2484245-1-arnd@kernel.org/ Signed-off-by:
-
- Sep 18, 2021
-
-
Linus Torvalds authored
The TGA boards were based on the DECchip 21030 PCI graphics accelerator used mainly for alpha, and existed in a TURBOchannel (TC) version for the DECstation (MIPS) workstations. However, the config option for the TGA code is a bit confused, and says depends on FB && (ALPHA || TC) because people didn't really want to enable the option for random PCI environments, so the "ALPHA" stands in for that case (while the TC case is then the MIPS DECstation case). So that config dependency is kind of a mixture of architecture and bus choices. But it's incorrect, in that there were non-PCI-based alpha hardware, and then the driver just causes warnings: drivers/video/fbdev/tgafb.c:1532:13: error: ‘tgafb_unregister’ defined but not used [-Werror=unused-function] 1532 | static void tgafb_unregister(struct device *dev) | ^~~~~~~~~~~~~~~~ drivers/video/fbdev/tgafb.c:1387:12: error: ‘tgafb_register’ defined but not used [-Werror=unused-function] 1387 | static int tgafb_register(struct device *dev) | ^~~~~~~~~~~~~~ so let's make the config option dependencies a bit more explict: depends on FB depends on PCI || TC depends on ALPHA || TC where that first "FB" is the software configuration dependency, the second "PCI || TC" is the hardware bus dependency, while that final "ALPHA || TC" dependency is the "don't bother asking except for these situations. We could make that third case have "COMPILE_TEST" as an option, and mark the register/unregister functions as __maybe_unused, but I'm not sure it's really worth it. Signed-off-by:
-
- Sep 08, 2021
-
-
Tetsuo Handa authored
syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multiplication overflow happens, let's reject in the common path. Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] Reported-by:
-
- Jul 27, 2021
-
-
Geert Uytterhoeven authored
Cache the column and page ranges, to avoid doing unneeded I2C transfers when the values haven't changed. Signed-off-by:
-
Geert Uytterhoeven authored
Currently, each screen update triggers an I2C transfer of all screen data, up to 1 KiB of data for a 128x64 display, which takes at least 20 ms in Fast mode. Reduce the amount of transferred data by only updating the rectangle that changed. Remove the calls to ssd1307fb_set_col_range() and ssd1307fb_set_page_range() during initialization, as ssd1307fb_update_rect() now takes care of that. Note that for now the optimized operation is only used for fillrect, copyarea, and imageblit, which are used by fbcon. Signed-off-by:
-
Geert Uytterhoeven authored
Extract the code to set the column and page ranges into two helper functions. Signed-off-by:
-
Geert Uytterhoeven authored
Simplify the nested loops to handle conversion from linear frame buffer to ssd1307 page layout: 1. Move last page handling one level up, as the value of "m" is the same inside a page, 2. array->data[] is filled linearly, so there is no need to recalculate array_idx over and over again; a simple increment is sufficient. Signed-off-by: -
Geert Uytterhoeven authored
Make ssd1307fb_update_display() return an error code, so callers that can handle failures can propagate it. Signed-off-by:
-
- Jul 26, 2021
-
-
Alexander Sverdlin authored
Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch to Common Clock Framework. Signed-off-by:
-
Zheyu Ma authored
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 error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by:
-
Zheyu Ma authored
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 error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by:
-
Zheyu Ma authored
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 error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by:
-
- Jul 21, 2021
-
-
Zheyu Ma authored
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 error because of the 'PICOS2KHZ' macro. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 53.093806] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 53.093838] CPU: 3 PID: 11763 Comm: hang Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0 #215 [ 53.093859] RIP: 0010:neofb_check_var+0x80/0xe50 [ 53.093951] Call Trace: [ 53.093956] ? neofb_setcolreg+0x2b0/0x2b0 [ 53.093968] fb_set_var+0x2e4/0xeb0 [ 53.093977] ? fb_blank+0x1a0/0x1a0 [ 53.093984] ? lock_acquire+0x1ef/0x530 [ 53.093996] ? lock_release+0x810/0x810 [ 53.094005] ? lock_is_held_type+0x100/0x140 [ 53.094016] ? ___might_sleep+0x1ee/0x2d0 [ 53.094028] ? __mutex_lock+0x620/0x1190 [ 53.094036] ? do_fb_ioctl+0x313/0x700 [ 53.094044] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 53.094051] ? __this_cpu_preempt_check+0x1d/0x30 [ 53.094060] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 53.094069] ? lockdep_hardirqs_on+0x59/0x100 [ 53.094076] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 53.094085] ? trace_hardirqs_on+0x6a/0x1c0 [ 53.094096] do_fb_ioctl+0x31e/0x700 Signed-off-by:
-
Colin Ian King authored
The variable err is being initialized with a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:
-
- Jul 19, 2021
-
-
Xiyu Yang authored
refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by:
-
Zheyu Ma authored
The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 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+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by:
-
- Jul 13, 2021
-
-
Gustavo A. R. Silva authored
Fix the following fallthrough warning (arm64-randconfig with Clang): drivers/video/fbdev/xilinxfb.c:244:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] Reported-by:
-
Zhen Lei authored
The execution of fb_delete_videomode() is not based on the result of the previous fbcon_mode_deleted(). As a result, the mode is directly deleted, regardless of whether it is still in use, which may cause UAF. ================================================================== BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Read of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 18960: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1541 [inline] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [inline] kfree+0xca/0x3d0 mm/slub.c:4121 fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 13ff178c ("fbcon: Call fbcon_mode_deleted/new_modelist directly") Signed-off-by:
-
- Jul 01, 2021
-
-
Andy Shevchenko authored
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helpers. There are several purposes of doing this: - dropping dependency in bug.h - dropping a loop by moving out panic_notifier.h - unload kernel.h from something which has its own domain At the same time convert users tree-wide to use new headers, although for the time being include new header back to kernel.h to avoid twisted indirected includes for existing users. [akpm@linux-foundation.org: thread_info.h needs limits.h] [andriy.shevchenko@linux.intel.com: ia64 fix] Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
- Jun 17, 2021
-
-
Jiahua Yu authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by:
-
- Jun 03, 2021
-
-
Zhen Lei authored
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
-
lijian authored
deleted the repeated word 'be' in the comments. Signed-off-by:
-
- Jun 01, 2021
-
-
Matthew Wilcox authored
Commit ccf953d8 makes framebuffers which use deferred I/O stop displaying updates after the first one. This is because the pages handled by fb_defio no longer have a page_mapping(). That prevents page_mkclean() from marking the PTEs as clean, and so writes are only noticed the first time. Reported-by:
-
- May 26, 2021
-
-
Arnd Bergmann authored
This is one of the last drivers with a global init_module() function instead of the modern module_init() annotation. Convert it over. Signed-off-by:
-
- May 21, 2021
-
-
Anirudh Rayabharam authored
The return value of hga_card_detect() is not properly handled causing the probe to succeed even though hga_card_detect() failed. Since probe succeeds, hgafb_open() can be called which will end up operating on an unmapped hga_vram. This results in an out-of-bounds access as reported by kernel test robot [1]. To fix this, correctly detect failure of hga_card_detect() by checking for a non-zero error code. [1]: https://lore.kernel.org/lkml/20210516150019.GB25903@xsang-OptiPlex-9020/ Fixes: dc13cac4 ("video: hgafb: fix potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Reported-by:
-
- May 15, 2021
-
-
Tetsuo Handa authored
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 <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <linux/kd.h> #include <linux/vt.h> 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:
-
- May 14, 2021
-
-
Andy Shevchenko authored
After the commit 72915994 ("video: ssd1307fb: Make use of device properties") driver does not depend on OF, drop unneeded dependency. Signed-off-by:
-
- May 13, 2021
-
-
Greg Kroah-Hartman authored
We should check if ioremap() were to somehow fail in imsttfb_probe() and handle the unwinding of the resources allocated here properly. Ideally if anyone cares about this driver (it's for a PowerMac era PCI display card), they wouldn't even be using fbdev anymore. Or the devm_* apis could be used, but that's just extra work for diminishing returns... Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by:
-
Greg Kroah-Hartman authored
This reverts commit 1d84353d. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit here, while technically correct, did not fully handle all of the reported issues that the commit stated it was fixing, so revert it until it can be "fixed" fully. Note, ioremap() probably will never fail for old hardware like this, and if anyone actually used this hardware (a PowerMac era PCI display card), they would not be using fbdev anymore. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Aditya Pakki <pakki001@umn.edu> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by:
-
Igor Matheus Andrade Torrente authored
The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference. The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect. Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit ec7f6aad. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This patch "looks" correct, but the driver keeps on running and will fail horribly right afterward if this error condition ever trips. So points for trying to resolve an issue, but a huge NEGATIVE value for providing a "fake" fix for the problem as nothing actually got resolved at all. I'll go fix this up properly... Cc: Kangjie Lu <kjlu@umn.edu> Cc: Aditya Pakki <pakki001@umn.edu> Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Fixes: ec7f6aad ("video: hgafb: fix potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-39-gregkh@linuxfoundation.org Signed-off-by:
-
- May 09, 2021
-
-
Linus Torvalds authored
Commit b9d79e4c ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- May 07, 2021
-
-
Christophe JAILLET authored
'ret' is known to be 0 here. No error code is available, so just remove it from the error message. Fixes: 72330b0e ("i.MX Framebuffer: Use readl/writel instead of direct pointer deref") Reviewed-by:
-
Masahiro Yamada authored
The section "19) Editor modelines and other cruft" in Documentation/process/coding-style.rst clearly says, "Do not include any of these in source files." I recently receive a patch to explicitly add a new one. Let's do treewide cleanups, otherwise some people follow the existing code and attempt to upstream their favoriate editor setups. It is even nicer if scripts/checkpatch.pl can check it. If we like to impose coding style in an editor-independent manner, I think editorconfig (patch [1]) is a saner solution. [1] https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/ Link: https://lkml.kernel.org/r/20210324054457.1477489-1-masahiroy@kernel.org Signed-off-by:
-
- May 04, 2021
-
-
Guenter Roeck authored
With CONFIG_PROC_FS=n and -Werror, 0-day reports: drivers/video/fbdev/core/fbmem.c:736:36: error: 'proc_fb_seq_ops' defined but not used Mark it as __maybe_unused. Reported-by:
-