[PATCH] leds: flash: leds-qcom-flash: Release all V4L2 flash devices

[PATCH] leds: flash: leds-qcom-flash: Release all V4L2 flash devices

[George Neacsu via B4 Relay]

From: George Neacsu <geocausa@gmail.com>

The probe error path and qcom_flash_led_remove() walk the V4L2 flash
array like this:

	while (flash_data->v4l2_flash[flash_data->leds_count] && flash_data->leds_count)
		v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);

leds_count is the number of registered LEDs, so the first test reads
one entry past the last registered one. The array holds exactly one
entry per LED child node, so after a full probe that read is out of
bounds. The loop also stops before index 0. With a single LED nothing
is released at all.

The V4L2 flash sub-device then stays registered after the driver is
unbound, still pointing at the driver's freed devm memory. On a Surface
Pro 11 (X1E80100, PM8550 flash, IR LED linked to a sensor through
flash-leds), unloading the module and then setting a flash control on
the sub-device triggered UBSAN shift-out-of-bounds reports and a NULL
pointer dereference in regmap_field_update_bits_base(), called from
update_allowed_flash_current().

Release the registered entries from leds_count - 1 down to 0.

Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: George Neacsu <geocausa@gmail.com>
---
 drivers/leds/flash/leds-qcom-flash.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/flash/leds-qcom-flash.c b/drivers/leds/flash/leds-qcom-flash.c
index b03a683..c2fefee 100644
--- a/drivers/leds/flash/leds-qcom-flash.c
+++ b/drivers/leds/flash/leds-qcom-flash.c
@@ -953,8 +953,8 @@ static int qcom_flash_led_probe(struct platform_device *pdev)
 
 	return regmap_field_write(flash_data->r_fields[REG_TORCH_CLAMP], flash_data->torch_clamp);
 release:
-	while (flash_data->v4l2_flash[flash_data->leds_count] && flash_data->leds_count)
-		v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
+	while (flash_data->leds_count)
+		v4l2_flash_release(flash_data->v4l2_flash[--flash_data->leds_count]);
 	return rc;
 }
 
@@ -962,8 +962,8 @@ static void qcom_flash_led_remove(struct platform_device *pdev)
 {
 	struct qcom_flash_data *flash_data = platform_get_drvdata(pdev);
 
-	while (flash_data->v4l2_flash[flash_data->leds_count] && flash_data->leds_count)
-		v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
+	while (flash_data->leds_count)
+		v4l2_flash_release(flash_data->v4l2_flash[--flash_data->leds_count]);
 
 	mutex_destroy(&flash_data->lock);
 }

---
base-commit: 62f482ff73bf3ae88b0c899115527752cf9cbf13
change-id: 20261016-qcom-flash-v4l2-release-9d05c97d1c47

Best regards,
-- 
George Neacsu <geocausa@gmail.com>

Re: [PATCH] leds: flash: leds-qcom-flash: Release all V4L2 flash devices

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] leds: missing mutex_destroy() on probe error paths
--

commit 02e8e6631f1731424fa6ad18e025af7434984559
Author: George Neacsu <geocausa@gmail.com>

leds: flash: leds-qcom-flash: Release all V4L2 flash devices

This commit fixes an out-of-bounds array access and a loop logic error
during probe failure and driver removal. It ensures all registered V4L2
flash sub-devices are correctly released.

> diff --git a/drivers/leds/flash/leds-qcom-flash.c b/drivers/leds/flash/leds-qcom-flash.c
> index b03a6833e3e3a..c2fefeec9b80c 100644
> --- a/drivers/leds/flash/leds-qcom-flash.c
> +++ b/drivers/leds/flash/leds-qcom-flash.c
> @@ -953,8 +953,8 @@ static int qcom_flash_led_probe(struct platform_device *pdev)
>  
>  	return regmap_field_write(flash_data->r_fields[REG_TORCH_CLAMP], flash_data->torch_clamp);
>  release:
> -	while (flash_data->v4l2_flash[flash_data->leds_count] && flash_data->leds_count)
> -		v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
> +	while (flash_data->leds_count)
> +		v4l2_flash_release(flash_data->v4l2_flash[--flash_data->leds_count]);

[Severity: Low]
Are we missing a call to mutex_destroy() for flash_data->lock on the error
paths?

Earlier in qcom_flash_led_probe(), the driver calls
mutex_init(&flash_data->lock). However, neither this release cleanup block
nor the earlier direct error returns destroy it:

	count = device_get_child_node_count(dev);
	if (count == 0 || count > flash_data->max_channels) {
		dev_err(dev, "No child or child count exceeds %d\n", ...);
		return -EINVAL;
	}

While the memory for flash_data is devres-managed, bypassing mutex_destroy()
omits CONFIG_DEBUG_MUTEXES validation hooks during teardown and leaves the
cleanup asymmetric compared to qcom_flash_led_remove().

>  	return rc;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-qcom-flash-v4l2-release-v1-1-0e92aa7c9327@gmail.com?part=1