kernel/drivers/video/fbdev/smscufx.c, branch linux-rolling-stable

fbdev: smscufx: properly copy ioctl memory to kernelspace

2026-02-19T15:31:35Z

commit 120adae7b42faa641179270c067864544a50ab69 upstream. The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel. Reported-by: Tianchu Chen Cc: stable Cc: Steve Glendinning Cc: Helge Deller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

fbdev: smscufx: Make I2C terminology more inclusive

2024-07-11T10:07:48Z

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan Signed-off-by: Helge Deller

fbdev: Push pgprot_decrypted() into mmap implementations

2023-11-29T11:20:44Z

If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically calls pgprot_decrypted(). But the default fb_mmap code doesn't handle pgprot_decrypted(). Move the call to pgprot_decrypted() into each drivers' fb_mmap function. This only concerns fb_mmap functions for system and DMA memory. For I/O memory, which is the default case, nothing changes. The fb_mmap for I/O-memory can later be moved into a helper as well. DRM's fbdev emulation handles pgprot_decrypted() internally via the Prime helpers. Fbdev doesn't have to do anything in this case. In cases where DRM uses deferred I/O, this patch updates fb_mmap correctly. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-30-tzimmermann@suse.de

fbdev/smscufx: Use fb_ops helpers for deferred I/O

2023-09-05T12:13:56Z

Generate callback functions for struct fb_ops with the fbdev macro FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to the generated functions with fbdev initializer macros. Signed-off-by: Thomas Zimmermann Cc: Steve Glendinning Acked-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230828132131.29295-2-tzimmermann@suse.de

fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structs

2023-07-24T14:50:38Z

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller Cc: Nicolas Ferre Cc: Benjamin Herrenschmidt Cc: Ferenc Bakonyi Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Wei Liu Cc: Dexuan Cui Cc: Antonino Daplas Cc: Maik Broemme Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Kristoffer Ericson Cc: Hans de Goede Cc: Steve Glendinning Cc: Bernie Thompson Cc: Florian Tobias Schandinat Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-6-tzimmermann@suse.de

fbdev/smscufx: Detect registered fb_info from refcount

2023-06-27T07:58:50Z

Detect registered instances of fb_info by reading the reference counter from struct fb_info.read. Avoids looking at the dev field and prepares fbdev for making struct fb_info.dev optional. Signed-off-by: Thomas Zimmermann Cc: Steve Glendinning Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-31-tzimmermann@suse.de

fbdev/smscufx: Use struct fb_info.screen_buffer

2023-05-08T13:28:33Z

Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-11-tzimmermann@suse.de

fbdev: smscufx: fix error handling code in ufx_usb_probe

2022-12-14T19:01:50Z

The current error handling code in ufx_usb_probe have many unmatching issues, e.g., missing ufx_free_usb_list, destroy_modedb label should only include framebuffer_release, fb_dealloc_cmap only matches fb_alloc_cmap. My local syzkaller reports a memory leak bug: memory leak in ufx_usb_probe BUG: memory leak unreferenced object 0xffff88802f879580 (size 128): comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s) hex dump (first 32 bytes): 80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|............. 00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................ backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045 [] kmalloc include/linux/slab.h:553 [inline] [] kzalloc include/linux/slab.h:689 [inline] [] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline] [] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] call_driver_probe drivers/base/dd.c:560 [inline] [] really_probe+0x12d/0x390 drivers/base/dd.c:639 [] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808 [] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936 [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008 [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [] device_add+0x642/0xdc0 drivers/base/core.c:3517 [] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170 [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [] call_driver_probe drivers/base/dd.c:560 [inline] [] really_probe+0x12d/0x390 drivers/base/dd.c:639 [] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 Fix this bug by rewriting the error handling code in ufx_usb_probe. Reported-by: syzkaller Tested-by: Dongliang Mu Signed-off-by: Dongliang Mu Signed-off-by: Helge Deller

fbdev: smscufx: Fix several use-after-free bugs

2022-10-21T05:36:32Z

Several types of UAFs can occur when physically removing a USB device. Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, and in this function, there is kref_put() that finally calls ufx_free(). This fix prevents multiple UAFs. Signed-off-by: Hyunwoo Kim Link: https://lore.kernel.org/linux-fbdev/20221011153436.GA4446@ubuntu/ Cc: Signed-off-by: Helge Deller

fbdev: smscufx: Fix use-after-free in ufx_ops_open()

2022-10-08T13:20:09Z

A race condition may occur if the user physically removes the USB device while calling open() for this device node. This is a race condition between the ufx_ops_open() function and the ufx_usb_disconnect() function, which may eventually result in UAF. So, add a mutex to the ufx_ops_open() and ufx_usb_disconnect() functions to avoid race contidion of krefs. Signed-off-by: Hyunwoo Kim Cc: stable@vger.kernel.org Signed-off-by: Helge Deller