Re: KASAN use-after-free report during piglit run

["Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Am 31.10.2017 um 18:58 schrieb Michel Dänzer:
> 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.

Good catch. But this means that just grabbing another reference before 
calling reservation_object_wait_timeout_rcu() and we should be on the 
safe side, shouldn't we ?

Going to take a closer look tomorrow, today is a holiday here and I'm 
actually ill again once more :(

Christian.

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx