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

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Wed Jul 22 02:03:15 UTC 2020


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

--- Comment #80 from Kees Cook (kees at 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

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


More information about the dri-devel mailing list