Reporting a use-after-free in amdgpu

[Christian König]

That looks like an incorrect error handling to me.

The invalid address is rejected and because of this we free up the data 
structures, but probably in the wrong order or something like that.

Going to take a look.

Thanks,
Christian.

Am 15.02.24 um 03:34 schrieb 정준교:
> Hello,
>
> We would like to report a use-after-free bug in the AMDGPU DRM driver 
> in the linux kernel 6.2 that we found with our customized Syzkaller.
> The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl 
> to the AMDGPU DRM driver, with invalid addr and size.
> We have tested that this bug can still be triggered in the latest RC 
> kernel, v6.8-rc4.
>
> Steps to reproduce are as below.
>
> struct drm_amdgpu_gem_userptr *arg;
> arg = malloc(sizeof(struct drm_amdgpu_gem_userptr));
> arg->addr = 0xffffffffffff0000;
> arg->size = 0x80000000;
> arg->flags = 0x7;
> ioctl(AMDGPU_renderD128_DEVICE_FILE, 0xc1186451, arg);
>
> The KASAN report is as follows:
> ==================================================================
> BUG: KASAN: use-after-free in switch_mm_irqs_off+0x89d/0xb70
> Read of size 8 at addr ffff88801f17bc00 by task syz-executor/386
> Call Trace:
> <TASK>
> switch_mm_irqs_off+0x89d/0xb70
> __schedule+0xa62/0x2630
> preempt_schedule_common+0x45/0xd0
> vfree+0x4d/0x60
> ttm_tt_fini+0xdf/0x1c0
> amdgpu_ttm_backend_destroy+0x9f/0xe0
> ttm_bo_cleanup_memtype_use+0x142/0x1f0
> ttm_bo_release+0x67d/0xc00
> ttm_bo_put+0x7c/0xa0
> amdgpu_bo_unref+0x3b/0x80
> amdgpu_gem_object_free+0x7f/0xc0
> drm_gem_object_free+0x5d/0x90
> amdgpu_gem_userptr_ioctl+0x452/0x7e0
> drm_ioctl_kernel+0x284/0x500
> drm_ioctl+0x55e/0xa50
> amdgpu_drm_ioctl+0xe3/0x1d0
> </TASK>
>
> Allocated by task 385:
> kmem_cache_alloc+0x174/0x300
> copy_process+0x32d1/0x6640
> kernel_clone+0xcd/0x690
>
> Freed by task 386:
> kmem_cache_free+0x13b/0x550
> mmu_interval_notifier_remove+0x4c8/0x610
> amdgpu_hmm_unregister+0x47/0x90
> amdgpu_gem_object_free+0x75/0xc0
> drm_gem_object_free+0x5d/0x90
> amdgpu_gem_userptr_ioctl+0x452/0x7e0
> drm_ioctl_kernel+0x284/0x500
> drm_ioctl+0x55e/0xa50
> amdgpu_drm_ioctl+0xe3/0x1d0
>
> The buggy address belongs to the object at ffff88801f17bb80
> which belongs to the cache mm_struct of size 2016
> The buggy address is located 128 bytes inside of
> 2016-byte region [ffff88801f17bb80, ffff88801f17c360)
>
> The buggy address belongs to the physical page:
> page:000000002c2a61bd refcount:1 mapcount:0 mapping:0000000000000000 
> index:0x0 pfn:0x1f178
> head:000000002c2a61bd order:3 compound_mapcount:0 subpages_mapcount:0 
> compound_pincount:0
> memcg:ffff8880141aa301
> flags: 0x100000000010200(slab|head|node=0|zone=1)
> raw: 0100000000010200 ffff88800a44fc80 ffffea00006ca400 dead000000000004
> raw: 0000000000000000 00000000800f000f 00000001ffffffff ffff8880141aa301
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88801f17bb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88801f17bb80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff88801f17bc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88801f17bc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88801f17bd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================