Hello, Thanks for your reply! The report is publicly available at https://sites.google.com/view/basscheck/home. And this patch is from the 8th report on this website.
Thanks, Tuo Li On Sat, Jul 1, 2023 at 4:01 PM Krzysztof Kozlowski < krzysztof.kozlow...@linaro.org> wrote: > On 30/06/2023 04:19, Tuo Li wrote: > > The variable crtc->state->event is often protected by the lock > > crtc->dev->event_lock when is accessed. However, it is accessed as a > > condition of an if statement in exynos_drm_crtc_atomic_disable() without > > holding the lock: > > > > if (crtc->state->event && !crtc->state->active) > > > > However, if crtc->state->event is changed to NULL by another thread right > > after the conditions of the if statement is checked to be true, a > > null-pointer dereference can occur in drm_crtc_send_vblank_event(): > > > > e->pipe = pipe; > > > > To fix this possible null-pointer dereference caused by data race, the > > spin lock coverage is extended to protect the if statement as well as > the > > function call to drm_crtc_send_vblank_event(). > > > > Reported-by: BassCheck <b...@buaa.edu.cn> > > I cannot find this report. This is an open source work and public > collaboration. The "Reported-by" usually means that the issue was > reported to us, in some way, usually in public. Can we see the report? > Otherwise adding non-public, non-verifiable reports is useless and > clutters our report-credit-system. > > Best regards, > Krzysztof > >
