Re: [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION
[email protected] Thu, 23 Jul 2026 16:56:51 +0000
| Newsgroups | org.kernel.vger.linux-leds |
|---|---|
| Message-ID | <[email protected]> |
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 <[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. > 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/[email protected]?part=1