Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/bridge: samsung-dsim: UAF in samsung_dsim_attach() due to data race --
commit c28866fd6b4a2bff1ae13053f73c850e270af34a Author: Luca Ceresoli <[email protected]> drm/bridge: samsung-dsim: move drm_bridge_add() call to probe This bridge driver calls drm_bridge_add() in the DSI host .attach callback instead of in the probe function. This looks strange, even though apparently not a problem for currently supported use cases. [ ... ] > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > b/drivers/gpu/drm/bridge/samsung-dsim.c > index 480e568dd2c9d..b2de447dc6f43 100644 > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1827,6 +1827,9 @@ static int samsung_dsim_attach(struct drm_bridge > *bridge, > { > struct samsung_dsim *dsi = bridge_to_dsi(bridge); > > + if (!dsi->bridge.next_bridge) > + return 0; > + > return drm_bridge_attach(encoder, dsi->bridge.next_bridge, bridge, > flags); > } [Severity: High] Could this lockless read of next_bridge introduce a use-after-free regression due to a time-of-check to time-of-use race condition? Since drm_bridge_add() is now called in probe(), the upstream encoder can attach the bridge while the downstream panel is asynchronously probing. This allows samsung_dsim_attach() to run concurrently with samsung_dsim_host_detach(). If the panel concurrently unbinds or detaches, samsung_dsim_host_detach() can clear the downstream bridge locklessly via: drm_bridge_clear_and_put(&dsi->bridge.next_bridge); If this concurrent clearing happens between the check here and the subsequent internal drm_bridge_get() call within drm_bridge_attach(), could the kernel execute a kref_get() on a freed bridge pointer? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=7
