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 <[email protected]> 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/[email protected]?part=1
