https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #80 from Kees Cook (kees@outflux.net) --- (In reply to mnrzk from comment #79)
I wonder if there's any way to set a watchpoint to see where exactly the dm_atomic_state gets filled with garbage data.
mm/slub.c set_freepointer() (via several possible paths through slab_free()) via writes the pointer. What you really want to know is "who called kfree() before this tried to read from here?".
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?
With CONFIG_SLAB_FREELIST_HARDENED=y the contents will be randomly permuted on a per-slab basis. Without, they'll look like a "regular" kernel heap pointer (0xffff....). You maybe have much more exciting failure modes without CONFIG_SLAB_FREELIST_HARDENED since the pointer will actually be valid. :P