Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] dsi->te_gpio is not cleared to NULL after being freed via gpiod_put() or after an ERR_PTR assignment. This leaves a dangling pointer that can lead to Use-After-Free and Double-Free bugs on subsequent attach/detach cycles or IRQ enable/disable operations. -- commit ae0d9af500f3fda4ddfaac130c60cd01aa1ce58f Author: Li Youhong <[email protected]> Subject: drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach This commit switches the TE GPIO acquisition back from devm_gpiod_get_optional() to gpiod_get_optional() to fix a lifetime issue on host detach/reattach. It keeps explicit gpiod_put() calls on the error path and in samsung_dsim_unregister_te_irq(). > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > b/drivers/gpu/drm/bridge/samsung-dsim.c > index e2fc69fc51b60..8f3fd50e52f80 100644 > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1862,7 +1862,8 @@ static int samsung_dsim_register_te_irq(struct > samsung_dsim *dsi, struct device > int te_gpio_irq; > int ret; > > - dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); > + /* Released on host detach; do not use the managed get. */ > + dsi->te_gpio = gpiod_get_optional(dev, "te", GPIOD_IN); > if (!dsi->te_gpio) > return 0; > else if (IS_ERR(dsi->te_gpio)) [Severity: High] This is a pre-existing issue, but is it possible we are leaving a dangling pointer in dsi->te_gpio here? If gpiod_get_optional() fails, dsi->te_gpio is assigned an error pointer and the function returns early, leaving the error pointer exposed in the dsi struct. If a video-mode panel is later attached and samsung_dsim_enable_irq() is called, could this lead to an invalid memory access when it operates on the error pointer? There appear to be similar pre-existing issues where dsi->te_gpio isn't cleared to NULL after being freed. For example, further down in the error handling of samsung_dsim_register_te_irq(): if (ret) { dev_err(dsi->dev, "request interrupt failed with %d\n", ret); gpiod_put(dsi->te_gpio); return ret; } And in samsung_dsim_unregister_te_irq(): if (dsi->te_gpio) { free_irq(gpiod_to_irq(dsi->te_gpio), dsi); gpiod_put(dsi->te_gpio); } Since this patch addresses detach/reattach cycles where the device isn't destroyed, if we switch from a command-mode panel to a video-mode panel, could these dangling pointers lead to a use-after-free or double-free on a subsequent cycle? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
