https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #78 from Kees Cook (kees@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.