https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #78 from Kees Cook (kees@xxxxxxxxxxx) --- (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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
