Re: [PATCH v2] fbdev: sh_mobile_lcdcfb: Restore the per-overlay sysfs attributes

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Framebuffer structure (`fb_info`) Use-After-Free and registration leak if `fb_device_create` fails.
- [High] Concurrent sysfs stores and fbdev ioctls cause data races and hardware register clobbering due to missing locks.
--

commit 2445fda1d6b2eaa304debdee2b9155ce76236747
Author: Karl Mehltretter <kmehltretter@gmail.com>

fbdev: sh_mobile_lcdcfb: Restore the per-overlay sysfs attributes

This commit restores the per-overlay sysfs attributes by renaming them and
registering the sysfs groups on each overlay's framebuffer device instead
of the platform driver's dev_groups. It also fixes incorrect dev_get_drvdata()
accesses caused by an earlier regression.

> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index e8324b01700f6..5743c96d54814 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
[ ... ]
> @@ -1337,22 +1337,24 @@ overlay_rop3_store(struct device *dev, struct device_attribute *attr,
>  	return count;
>  }
>  
> -static DEVICE_ATTR_RW(overlay_alpha);
> -static DEVICE_ATTR_RW(overlay_mode);
> -static DEVICE_ATTR_RW(overlay_position);
> -static DEVICE_ATTR_RW(overlay_rop3);
> -
> -static struct attribute *overlay_sysfs_attrs[] __maybe_unused = {
> -	&dev_attr_overlay_alpha.attr,
> -	&dev_attr_overlay_mode.attr,
> -	&dev_attr_overlay_position.attr,
> -	&dev_attr_overlay_rop3.attr,
> +static struct device_attribute dev_attr_ovl_alpha =
> +	__ATTR(ovl_alpha, 0644, overlay_alpha_show, overlay_alpha_store);

[Severity: High]
This isn't a bug introduced by this patch, but do these sysfs store
callbacks need locking to prevent hardware state corruption?

Functions like overlay_alpha_store() and overlay_rop3_store() modify
overlay state variables and call sh_mobile_lcdc_overlay_setup() to perform
direct I/O writes to the LCDC hardware registers without acquiring any locks.

Concurrently, standard fbdev ioctls like fb_blank() modify the same state
and call sh_mobile_lcdc_overlay_setup() from sh_mobile_lcdc_overlay_blank()
while properly holding info->lock.

Could concurrent sysfs writes and fbdev ioctls interleave register writes and
clobber the hardware state?

[ ... ]
> @@ -1510,9 +1512,10 @@ sh_mobile_lcdc_overlay_fb_unregister(struct sh_mobile_lcdc_overlay *ovl)
>  {
>  	struct fb_info *info = ovl->info;
>  
> -	if (info == NULL || info->dev == NULL)
> +	if (!info || !dev_of_fbinfo(info))
>  		return;

[Severity: High]
This is a pre-existing issue, but does this early return cause a memory leak
and use-after-free in the fbdev core?

If fb_device_create() fails due to memory pressure or sysfs conflicts,
info->dev is set to NULL but register_framebuffer() still returns success.
When tearing down the device, this check for dev_of_fbinfo() evaluates to
true and causes an early return, bypassing unregister_framebuffer().

Later, sh_mobile_lcdc_overlay_fb_cleanup() calls framebuffer_release(), which
frees the fb_info structure while it is still linked in the fbdev core's
registered_fb array.

Can unregister_framebuffer() be called regardless of whether device creation
succeeded, both here and in sh_mobile_lcdc_channel_fb_unregister()?

>  
> +	device_remove_groups(dev_of_fbinfo(info), overlay_sysfs_groups);
>  	unregister_framebuffer(ovl->info);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912102152.86744-1-kmehltretter@gmail.com?part=1