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