Re: [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION

[sashiko-bot@kernel.org]

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

New issues:
- [Low] The commit message claims MODULE_DESCRIPTION is required by modpost for this driver, but the driver is unconditionally built-in.
- [Low] The commit message description is not capitalized, violating subsystem guidelines.

Pre-existing issues:
- [High] Unmanaged LED registration combined with managed memory mapping without a `.remove` callback leads to a use-after-free on device unbind.
--

--- Patch [1]: [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION ---
commit f1b0026d062cbcf0e980882e66d901b8eb8e018f
Author: Arunachalam <arun07172003@gmail.com>

leds: cobalt-raq: add missing MODULE_DESCRIPTION

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

> leds: cobalt-raq: add missing MODULE_DESCRIPTION

[Severity: Low]
This isn't a bug, but the subsystem guidelines request capitalizing the
description after the prefix. Should this be "Add missing MODULE_DESCRIPTION"?

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

[Severity: Low]
Is this description accurate? This driver is defined as a bool in Kconfig,
meaning it can only be built-in. Modpost only checks for MODULE_DESCRIPTION
in loadable modules, so is this macro actually required here?

> diff --git a/drivers/leds/leds-cobalt-raq.c b/drivers/leds/leds-cobalt-raq.c
> index 045c239c7328e..5b5acaa8c3215 100644
> --- 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 is a pre-existing issue, but does the lack of a .remove callback here
leave a use-after-free window?

If a privileged user unbinds the driver via sysfs, the driver core will
automatically release devm resources, unmapping led_port. Since the LEDs were
registered with led_classdev_register() in cobalt_raq_led_probe() without
using the managed API, they remain registered.

Would a subsequent write to the LED's brightness file trigger
raq_web_led_set() and write to the now-unmapped led_port?

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

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