[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #79 from mnrzk at protonmail.com ---
(In reply to Kees Cook from comment #78)
> (In reply to mnrzk from comment #76)
> > If my understanding is correct, base would have previously been filled with
> > the freelist pointer (since it's the first 8 bytes). Now since the freelist
> > pointer is being put in the middle (rounded to the nearest sizeof(void*),
> >  or 8 bytes), it's being put in the last 8 bytes of *dm_state
> > (or dm_state->context).
> > 
> > I'll place a void* for padding in the middle of struct dm_atomic_state* and
> > if my hypothesis is correct, the padding will be filled with garbage data
> > instead of context and the bug should be fixed. Of course, there would
> > still be a use-after-free bug in the code which may cause other issues in
> > the future so I wouldn't really consider it a solution.
> 
> Agreed: that should make it disappear again, but as you say, it's just
> kicking the problem down the road since now the failing condition is losing
> a race with kfree()+kmalloc()+new contents.
> 
> And if you want to detect without crashing, you can just zero the padding at
> init time and report when it's non-NULL at workqueue run time... I wonder if
> KASAN can run in a mode where the allocation/freeing tracking happens, but
> without the heavy checking instrumentation? Then when the corruption is
> detected, it could dump a traceback about who did the early kfree()... hmmm.

So far I've been testing it by passing my GPU to my VM via vfio-pci and
attaching kgdb to the guest. To test if the context was invalid, I added
a check to make sure the context pointer wasn't garbage data (by checking
if dc_state was not null and the upper 16 bits were set on dc_state).

I wonder if there's any way to set a watchpoint to see where exactly the
dm_atomic_state gets filled with garbage data.

Also, since I'm not too familiar with freelists, do freelist pointers look
like regular pointers? On a regular pointer on a system with a 48-bit
virtual address space, regular pointers would be something like
0xffffXXXXXXXXXXXX. I've noticed that the data being inserted never
followed this format. Is this something valuable to note or is that just
the nature of freelist pointers?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.