Re: [PATCH v4] video: fbdev: via: refactor strcpy and viafb_name

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Struct memory copy corrupts `bl_curve_mutex` state inside the allocated secondary framebuffer structure.
--

--- Patch [1]: [PATCH v4] video: fbdev: via: refactor strcpy and viafb_name ---
commit 89ff079954842cbfcf9a3daa9bead9f4e5a2902d
Author: Ajith P V <[email protected]>

video: fbdev: via: refactor strcpy and viafb_name

Eliminate the single-use file-scope variable viafb_name and pass the
"Via" string literal directly to strcpy().

> diff --git a/drivers/video/fbdev/via/viafbdev.c b/drivers/video/fbdev/via/viafbdev.c
> index 80f95dac32c8c..dd9374e8ad098 100644
> --- a/drivers/video/fbdev/via/viafbdev.c
> +++ b/drivers/video/fbdev/via/viafbdev.c
> @@ -16,7 +16,6 @@
>  #define _MASTER_FILE
>  #include "global.h"
>  
> -static char *viafb_name = "Via";
>  static u32 pseudo_pal[17];
>  
>  /* video mode */

[ ... ]

[Severity: Critical]
This is a pre-existing issue, but does this struct memory copy cause a
regression by corrupting the bl_curve_mutex state inside the allocated
secondary framebuffer structure?

drivers/video/fbdev/via/viafbdev.c:via_fb_pci_probe() {
    ...
		viaparinfo->iga_path = IGA1;
		viaparinfo1->iga_path = IGA2;
		memcpy(viafbinfo1, viafbinfo, sizeof(struct fb_info));
		viafbinfo1->par = viaparinfo1;
    ...
}

During dual framebuffer initialization, viafbinfo1 is allocated using
framebuffer_alloc(), which properly initializes bl_curve_mutex.

This memcpy() performs a bitwise copy of a struct fb_info over another,
which blindly overwrites the initialized mutex with the bitwise state of
viafbinfo's mutex.

Because a mutex contains a self-referencing list head for its wait list,
would viafbinfo1's wait list pointers now incorrectly point to viafbinfo's
wait list?

When backlight support is enabled, an unprivileged user space program
can trigger concurrent reads or writes to /sys/class/graphics/fb1/bl_curve,
which attempts to take viafbinfo1->bl_curve_mutex.

Could modifying this corrupted wait list cause severe list corruption across
both framebuffers or a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1