Re: [PATCH next] drivers/video/fbdev/s3fb: Use strscpy() to copy strings into arrays

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Out-of-bounds array read in `s3_names` due to unvalidated PCI `driver_data` provided via sysfs `new_id`.
--

commit b390c20a52cf582227c3e8af3febb7b07f89b2a7
Author: David Laight <david.laight.linux@gmail.com>

drivers/video/fbdev/s3fb: Use strscpy() to copy strings into arrays

This commit replaces strcpy() with strscpy() in s3_pci_probe() to ensure
that target buffer overflows cannot occur.

> diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
> index ba30e5568cabc..b679ccdb38e2c 100644
> --- a/drivers/video/fbdev/s3fb.c
> +++ b/drivers/video/fbdev/s3fb.c
[ ... ]
> @@ -1333,7 +1333,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>  	vga_wcrt(par->state.vgabase, 0x38, cr38);
>  	vga_wcrt(par->state.vgabase, 0x39, cr39);
>  
> -	strcpy(info->fix.id, s3_names [par->chip]);
> +	strscpy(info->fix.id, s3_names[par->chip]);

[Severity: High]
This is a pre-existing issue, but does this array access risk an
out-of-bounds read if a privileged user provides a dynamic PCI ID?

In s3_pci_probe() in drivers/video/fbdev/s3fb.c, par->chip is derived
from the PCI driver_data:

s3_pci_probe() {
        ...
        par->chip = id->driver_data & CHIP_MASK;
        par->rev = vga_rcrt(par->state.vgabase, 0x2f);
        if (par->chip & CHIP_UNDECIDED_FLAG)
                par->chip = s3_identification(par);
        ...
}

If a user binds the driver via the sysfs new_id interface and supplies
a driver_data value between 21 and 127, it safely bypasses the
CHIP_UNDECIDED_FLAG (0x80) check. This leaves par->chip unvalidated.

Since the s3_names array contains exactly 21 elements, using this
unvalidated par->chip as an index could result in reading past the
end of the array. Passing the resulting invalid pointer to strscpy()
could then trigger an invalid memory dereference.

Should we add a bounds check for par->chip before accessing s3_names[]?

>  	info->fix.mmio_start = 0;
>  	info->fix.mmio_len = 0;
>  	info->fix.type = FB_TYPE_PACKED_PIXELS;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608095523.2606-11-david.laight.linux@gmail.com?part=1