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

[bugzilla-daemon at bugzilla.kernel.org]

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

--- Comment #85 from mnrzk at protonmail.com ---
(In reply to Christian König from comment #83)
> Instead of working around the bug I think we should concentrate on nailing
> the root cause.
> 
> I suggest to insert an use after free check into just that structure. In
> other words add a field "magic_number" will it with 0xdeadbeef on allocation
> and set it to zero before the kfree().
> 
> A simple BUG_ON(ptr->magic_number != 0xdeadbeef) should yield results rather
> quickly.
> 
> Then just add printk()s before the kfree() to figure out why we have this
> use after free race.

Fair point, I was just trying to confirm my hypothesis.

I realised why the test failed, adding 8 bytes of padding to the middle
made the struct size 24 bytes. Since the freelist pointer is being added
to the middle (12 bytes) and that's aligned to the nearest 8 bytes, the
pointer ended up being placed at an offset of 16 bytes (context).

After making the padding an array of 2 void* and initialising it to
{0xDEADBEEFCAFEF00D, 0x1BADF00D1BADC0DE}, the padding was eventually
corrupted with the context being left intact and therefore, no crashing.

GDB output of dm_struct:
{
    base = {state = 0xffff888273884c00},
    padding = {0xdeadbeefcafef00d, 0x513df83afd3ad7b2},
    context = 0xffff88824e680000
}

That said, I still don't know the root cause of the bug, I'll see
if I can use KASAN or something to figure out what exactly freed
dm_state. If anyone is more familiar with this code has any advice
for me, please let me know.

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