Re: [PATCH v3 1/4] leds: cobalt-raq: Add missing MODULE_DESCRIPTION

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

Pre-existing issues:
- [High] Use-After-Unmap and orphaned LED classdevs due to missing .remove callback combined with unmanaged led_classdev_register.
--

--- Patch [1]: [PATCH v3 1/4] leds: cobalt-raq: Add missing MODULE_DESCRIPTION ---
commit d2016764a88879b346e156b26cea14e3d81dd4b0
Author: Arunachalam <[email protected]>

leds: cobalt-raq: Add missing MODULE_DESCRIPTION

Add the missing MODULE_DESCRIPTION() macro, which is required by
modpost and was missing from this driver.

> diff --git a/drivers/leds/leds-cobalt-raq.c b/drivers/leds/leds-cobalt-raq.c
> --- a/drivers/leds/leds-cobalt-raq.c
> +++ b/drivers/leds/leds-cobalt-raq.c
> @@ -101,5 +101,5 @@ static struct platform_driver cobalt_raq_led_driver = {
>  		.name	= "cobalt-raq-leds",
>  	},
>  };

[Severity: High]
This isn't a bug introduced by this patch, but is a pre-existing flaw in
the driver.

Does this driver leave orphaned LED classdevs if it is unbound via sysfs?

The LEDs are registered in cobalt_raq_led_probe() using the unmanaged
led_classdev_register() API, but the driver definition here lacks a .remove
callback.

If a privileged user unbinds the driver, the devres cleanup will unmap
led_port. Because the LEDs are not unregistered, they will remain in the
subsystem. Any subsequent access to the sysfs brightness files will execute
raq_power_off_led_set() or raq_web_led_set() and attempt to write to the
unmapped led_port pointer, causing an invalid memory access.

Should this driver be updated to use devm_led_classdev_register() during
probe, or have a .remove callback added to ensure symmetric cleanup?

> -
> +MODULE_DESCRIPTION("LEDs driver for the Cobalt Raq series");
>  builtin_platform_driver(cobalt_raq_led_driver);

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