Re: [PATCH v2 1/2] leds: flash: Prevent using uninitialized variable in flash_fault_show()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Use-after-free due to missing indicator LED unregistration on probe error path.
- [Medium] Accumulating fault state in V4L2 flash controls due to uncleared variable.
--

commit 9123f63288afc4cb1ae08569252a324f5721a8b4
Author: Dmitry Antipov <dmantipov@yandex.ru>

leds: flash: Prevent using uninitialized variable in flash_fault_show()

This commit initializes the fault variable in flash_fault_show() to prevent
undefined behavior. This occurs when driver callbacks only perform bitwise
ORs without clearing the pointer first.

Closes: https://sashiko.dev/#/patchset/20260904054437.461706-1-dmantipov@yandex.ru?part=1

> diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
> index 6fe9d700dfef6..e10a9c796c04c 100644
> --- a/drivers/leds/led-class-flash.c
> +++ b/drivers/leds/led-class-flash.c
> @@ -188,7 +188,7 @@ static ssize_t flash_fault_show(struct device *dev,
>  {
>  	struct led_classdev *led_cdev = dev_get_drvdata(dev);
>  	struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
> -	u32 fault, mask = 0x1;
> +	u32 fault = 0, mask = 0x1;

[Severity: Medium]
This is a pre-existing issue, but while this commit fixes the
uninitialized variable in flash_fault_show(), does the exact same issue
exist in the V4L2 flash controls?

In drivers/media/v4l2-core/v4l2-flash-led-class.c:v4l2_flash_g_volatile_ctrl():

    case V4L2_CID_FLASH_FAULT:
        /* LED faults map directly to V4L2 flash faults */
        return led_get_flash_fault(fled_cdev, &c->val);

If a user-space process issues a volatile read for V4L2_CID_FLASH_FAULT,
c->val retains its previously cached value. Because underlying callbacks
like as3645a_get_fault() in drivers/leds/flash/leds-as3645a.c only
perform bitwise OR operations without clearing the pointer:

    if (rval & AS_FAULT_INFO_INDUCTOR_PEAK_LIMIT)
        *fault |= LED_FAULT_OVER_CURRENT;

cleared hardware faults will permanently remain stuck in the reported
V4L2 state until the module is reloaded. Could c->val be cleared before
calling led_get_flash_fault() here as well?

[Severity: High]
This is a pre-existing issue, but looking at the as3645a driver
mentioned above, is there a memory corruption concern on its probe error
path due to missing unregistration of the indicator LED?

In drivers/leds/flash/leds-as3645a.c:as3645a_probe():

    out_led_classdev_flash_unregister:
        led_classdev_flash_unregister(&flash->fled);

    out_mutex_destroy:

If as3645a_v4l2_setup() fails during device probe, the error path
unregisters the flash LED but completely misses unregistering the
indicator LED, iled_cdev, which was manually registered in
as3645a_led_class_setup().

The probe function returns an error, causing the devres framework to
automatically free the devm-allocated flash driver data structure. The
indicator LED remains fully registered and exposed to user-space sysfs.
Accessing its sysfs attributes will dereference the freed flash struct,
leading to a use-after-free. Would it make sense to call
led_classdev_unregister() for the indicator LED in this error path?

>  	char *pbuf = buf;
>  	int i, ret, buf_len;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904070806.19125-1-dmantipov@yandex.ru?part=1