[PATCH] drm: use atomic helper function to get crtc_state of crtc

Ville Syrjälä ville.syrjala at linux.intel.com
Tue Jun 19 15:48:52 UTC 2018


On Tue, Jun 19, 2018 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Tue, Jun 19, 2018 at 10:45:31AM -0400, mikita.lipski at amd.com wrote:
> > From: Mikita Lipski <mikita.lipski at amd.com>
> > 
> > Use drm_atomic_get_crtc_state to get the crtc state in case
> > it has been previously freed, that might prevent use-after-free issue.
> > 
> > This patch fixes the bugzilla bug:
> > Bug 199425 - BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
> > 
> > Signed-off-by: Mikita Lipski <mikita.lipski at amd.com>
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index e8c2493..e083f85 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1276,9 +1276,11 @@ void drm_atomic_helper_wait_for_flip_done(struct drm_device *dev,
> >  	int i;
> >  
> >  	for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> > -		struct drm_crtc_commit *commit = new_crtc_state->commit;
> > +		struct drm_crtc_commit *commit;
> >  		int ret;
> >  
> > +		new_crtc_state = drm_atomic_get_crtc_state(old_state, crtc);
> > +		commit = new_crtc_state->commit;
> 
> Uh no. wait_for_flip done is supposed to be called from the
> ->atomic_commit hook, and duplicating state objects (as is done by the
> various get_foo_state functions) is only allowed from the ->atomic_check
> hook. What that blows up for you, this isn't the fix you're looking for.
> Aside: get_foo_state can fail, the __must_check annotation should have
> been a hint for that.
> 
> For starters it would be useful if you include the full details of what's
> going boom in the amdgpu driver for you.

>From a quick glance at the bug report it looks like a cursor update
getting ahead of a page flip.

Actually I'm not even sure how this manages to work on i915. On i915
we allow the cursor update to go through as soon as hw_done is
completed. That would seem to mean that all the cleanup work
commit_tail does afterwards is at risk of using a freed plane state.
Well, maybe. The way this is all implemented doesn't really agree
with my brain so I can't be 100% sure.

Whacking a big sleep just after drm_atomic_helper_commit_hw_done()
should be able to confirm that I suppose.

-- 
Ville Syrjälä
Intel


More information about the dri-devel mailing list