On 25/10/17 05:43 PM, Michel Dänzer wrote: > > KASAN caught another use-after-free on my development machine today, see > the attached dmesg excerpt. There haven't been any related changes in > amd-staging-drm-next since yesterday, so maybe userspace is just > tickling the kernel differently (e.g. piglit runs some more tests in > parallel now). It's not reproducible every time, but it just happened a > second time (with an amd-staging-drm-next commit from about a week ago). I took a closer look, and I think I see what's happening. The use-after-free happens at: reservation_object_wait_timeout_rcu+0xe02/0xe90 ttm_bo_cleanup_refs_and_unlock+0x271/0x990 [ttm] (ttm_bo.c:530) ttm_mem_evict_first+0x263/0x4a0 [ttm] The memory was freed at: [reservation_object_fini] ttm_bo_cleanup_refs_and_unlock+0x517/0x990 [ttm] (ttm_bo.c:564) ttm_mem_evict_first+0x263/0x4a0 [ttm] So it's two processes handling the same BO in ttm_mem_evict_first -> ttm_bo_cleanup_refs_and_unlock. The first one unreserved the BO before calling reservation_object_wait_timeout_rcu. Meanwhile, the other one manages to reserve the BO and get all the way to the end of ttm_bo_cleanup_refs_and_unlock, destroying bo->ttm_resv. Then reservation_object_wait_timeout_rcu in the first process still accesses memory which bo->ttm_resv pointed to => boom. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
