Re: [PATCH v3 1/4] backlight: qcom-wled: Fix NULL pointer dereference in PM callbacks

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] Type confusion in wled_probe() and wled_remove() leading to memory corruption

Pre-existing issues:
- [High] Use-After-Free due to devres teardown order in wled_remove()
--

commit a2bfdd5e4b8eca63712840cdae737878170273a7
Author: David Heidelberg <david@ixit.cz>
Subject: backlight: qcom-wled: Fix NULL pointer dereference in PM callbacks

This patch attempts to fix a NULL pointer dereference during PM callbacks
by setting the platform device driver data in wled_probe().

> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
> index 650dd95f06ef5..a76158a298335 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -1752,6 +1752,7 @@ static int wled_probe(struct platform_device *pdev)
>  	bl = devm_backlight_device_register(&pdev->dev, wled->name,
>  					    &pdev->dev, wled,
>  					    &wled_ops, &props);

[Severity: High]
This is a pre-existing issue, but can using devres to register the backlight
device lead to a use-after-free regression during driver unbind?

Because the backlight device remains registered and accessible via sysfs
during and immediately after wled_remove() completes, could a concurrent
userspace write trigger wled_update_status() which calls
wled_module_enable()?

If this happens, it could re-schedule ovp_work after wled_remove() has
already canceled it:

wled_module_enable()
    schedule_delayed_work(&wled->ovp_work, HZ / 100);

Will this pending timer later execute on freed memory once devres cleans up
the wled structure?

> +	platform_set_drvdata(pdev, bl);

[Severity: Critical]
Does this code introduce a type mismatch regression?

wled_remove() expects the driver data to be a struct wled pointer:

wled_remove()
    struct wled *wled = platform_get_drvdata(pdev);

If we set it to the backlight_device pointer here, will wled_remove()
operate on invalid memory offsets when it later calls
mutex_destroy(&wled->lock) and cancel_delayed_work_sync(&wled->ovp_work)?

>  	return PTR_ERR_OR_ZERO(bl);
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-qcom-wled-backlight-v3-0-d69fe9843841@ixit.cz?part=1