[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Tue Jul 21 20:56:28 UTC 2020
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #78 from Kees Cook (kees at outflux.net) ---
(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.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the dri-devel
mailing list