leds: ktd2692: Pass context to regulator cleanup

PATCH Applied Myeonghun Pak 3 participants 3 messages Sep 10 – Sep 22

Subsystems (2)

Stable branch LED

lore

Share & tools

lore

Myeonghun Pak

author

2026-09-10 19:45 UTC #0 lore raw

PATCH 1/1 leds: ktd2692: Pass context to regulator cleanup

regulator_disable_action() retrieves the driver context from device driver data. However, ktd2692_parse_dt() registers the action before ktd2692_probe() stores the context with platform_set_drvdata().

If devm_add_action_or_reset() cannot allocate the action, it invokes the callback immediately. A later probe failure also invokes it during managed-resource unwinding. Both paths dereference a NULL context.

Pass the already allocated context directly to the action and retain the device pointer in it for error reporting. The context is allocated before the action is registered, so reverse-order devres unwinding keeps it alive through the callback.

This issue was identified during our ongoing static-analysis research while reviewing kernel code.

Fixes ee78b9360e14 ("leds: ktd2692: Fix an error handling path")

Cc [email protected]

Co-developed-by Ijae Kim <[email protected]>

Signed-off-by Ijae Kim <[email protected]>

Signed-off-by Myeonghun Pak <[email protected]>

---
 drivers/leds/flash/leds-ktd2692.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/leds/flash/leds-ktd2692.c +6 -4

index 22fbfccd4873549baf390127d2f7e9aeb9c45465..43d4d55503ab50c6e31b8e83eed430cc33e014e3 100644
@@ -69,6 +69,8 @@ static const struct expresswire_timing ktd2692_timing = {
 };
 
 struct ktd2692_context {
+	struct device *dev;
+
 	/* Common ExpressWire properties (ctrl GPIO and timing) */
 	struct expresswire_common_props props;

@@ -196,13 +198,12 @@ static void ktd2692_setup(struct ktd2692_context *led)
 
 static void regulator_disable_action(void *_data)
 {
-	struct device *dev = _data;
-	struct ktd2692_context *led = dev_get_drvdata(dev);
+	struct ktd2692_context *led = _data;
 	int ret;
 
 	ret = regulator_disable(led->regulator);
 	if (ret)
-		dev_err(dev, "Failed to disable supply: %d\n", ret);
+		dev_err(led->dev, "Failed to disable supply: %d\n", ret);
 }
 
 static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,

@@ -233,7 +234,7 @@ static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,
 			dev_err(dev, "Failed to enable supply: %d\n", ret);
 		} else {
 			ret = devm_add_action_or_reset(dev,
-						regulator_disable_action, dev);
+						regulator_disable_action, led);
 			if (ret)
 				return ret;
 		}

@@ -290,6 +291,7 @@ static int ktd2692_probe(struct platform_device *pdev)
 	if (!led)
 		return -ENOMEM;
 
+	led->dev = &pdev->dev;
 	fled_cdev = &led->fled_cdev;
 	led_cdev = &fled_cdev->led_cdev;
 	led->props.timing = ktd2692_timing;

Signature · 1 line

2.50.1

[email protected]

AI review

2026-09-10 19:56 UTC #1 lore raw

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

Pre-existing issues:
- [High] Silent suppression of -EPROBE_DEFER from devm_regulator_get() and missing return on regulator_enable() failure.
- [High] Race condition exposing the LED device to userspace before hardware setup is complete.
- [High] Kernel panic due to division by zero if flash-max-timeout-us is configured too small.
--

commit 6025dd2c27de45e105ee950ad7b4f5c0824e9c17
Author: Myeonghun Pak <[email protected]>

leds: ktd2692: Pass context to regulator cleanup

This commit fixes a NULL pointer dereference in the regulator disable action. It passes the allocated driver context directly to devm_add_action_or_reset() instead of relying on platform_get_drvdata() which is uninitialized at that point.

Quoted 4 lines

drivers/leds/flash/leds-ktd2692.c +0 -0
index 22fbfccd48735..43d4d55503ab5 100644

[ ... ]

drivers/leds/flash/leds-ktd2692.c static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev, · line 240

Quoted 9 lines

drivers/leds/flash/leds-ktd2692.c +1 -1

@@ -233,7 +234,7 @@ static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,
 			dev_err(dev, "Failed to enable supply: %d\n", ret);
 		} else {
 			ret = devm_add_action_or_reset(dev,
-						regulator_disable_action, dev);
+						regulator_disable_action, led);
 			if (ret)
 				return ret;
 		}

[Severity: High]
This isn't a bug introduced by this patch, but does ktd2692_parse_dt() silently suppress probe deferral and missing regulator errors?

If devm_regulator_get() returns -EPROBE_DEFER, the error is swallowed:

	led->regulator = devm_regulator_get(dev, "vin");
	if (IS_ERR(led->regulator))
		led->regulator = NULL;

Additionally, if regulator_enable() fails, it prints an error but continues probing without power instead of returning the error code:

	if (led->regulator) {
		ret = regulator_enable(led->regulator);
		if (ret) {
			dev_err(dev, "Failed to enable supply: %d\n", ret);
		} else {

Should the driver properly propagate -EPROBE_DEFER and return the failure from regulator_enable()?

[ ... ]

drivers/leds/flash/leds-ktd2692.c static int ktd2692_probe(struct platform_device *pdev) · line 297

Quoted 8 lines

drivers/leds/flash/leds-ktd2692.c +1 -0

@@ -290,6 +291,7 @@ static int ktd2692_probe(struct platform_device *pdev)
 	if (!led)
 		return -ENOMEM;
 
+	led->dev = &pdev->dev;
 	fled_cdev = &led->fled_cdev;
 	led_cdev = &fled_cdev->led_cdev;
 	led->props.timing = ktd2692_timing;

[Severity: High]
This is a pre-existing issue, but does ktd2692_probe() expose the LED device to userspace before hardware setup is complete?

led_classdev_flash_register() exposes the device to userspace sysfs. ktd2692_setup() is called afterward:

	ret = led_classdev_flash_register(&pdev->dev, fled_cdev);
	if (ret) {
		dev_err(&pdev->dev, "can't register LED %s\n", led_cdev->name);
		mutex_destroy(&led->lock);
		return ret;
	}

	ktd2692_setup(led);

If userspace writes to sysfs (e.g., brightness) in the race window, it could trigger ktd2692_led_brightness_set() before or during ktd2692_setup().

Could this lead to concurrent access to uninitialized hardware?

[Severity: High]
This is a pre-existing issue, but can the driver trigger a kernel panic due to a division by zero if flash-max-timeout-us is configured too small?

If flash-max-timeout-us in the Device Tree is less than 7, setting->step evaluates to 0 in ktd2692_init_flash_timeout():

	setting->step = cfg->flash_max_timeout
			/ (KTD2692_FLASH_MODE_TIMEOUT_LEVELS - 1);

Later, when userspace triggers a flash strobe via sysfs, ktd2692_led_flash_strobe_set() executes GET_TIMEOUT_OFFSET, which divides by step (which is 0):

	flash_tm_reg = GET_TIMEOUT_OFFSET(timeout->val, timeout->step);

Could this cause a division by zero? Should the driver validate the minimum value of flash-max-timeout-us during initialization?

Signature · 1 line

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

Lee Jones

maintainer Applied

2026-09-22 11:01 UTC #2 lore raw

Re: (subset) [PATCH] leds: ktd2692: Pass context to regulator cleanup

In reply to Myeonghun Pak

Quoted 9 lines · Myeonghun Pak

regulator_disable_action() retrieves the driver context from device driver data. However, ktd2692_parse_dt() registers the action before ktd2692_probe() stores the context with platform_set_drvdata().
If devm_add_action_or_reset() cannot allocate the action, it invokes the callback immediately. A later probe failure also invokes it during managed-resource unwinding. Both paths dereference a NULL context.
[...]

Applied, thanks!

[1/1] leds: ktd2692: Pass context to regulator cleanup

      commit: c73e9f04445f361d5f19ca2edfde742ce18348ef

--
Lee Jones [李琼斯]