Hello,
thank you for patching the first bug we have sent!
Just a quick touch base with you, to ask if there has been any update on our other two bugs.
They were each sent with emails titled
"Reporting a slab-use-after-free in amdgpu" (this one)
"Reporting a null-ptr-deref in amdgpu".
Thank you!
Best,
Joonkyo
2024년 2월 16일 (금) 오후 6:22, Joonkyo Jung <joonkyoj@xxxxxxxxxxxx>님이 작성:
Hello,
We would like to report a slab-use-after-free bug in the AMDGPU DRM driver in the linux kernel v6.8-rc4 that we found with our customized Syzkaller.
The bug can be triggered by sending two ioctls to the AMDGPU DRM driver in succession.
In amdgpu_bo_move, struct ttm_resource *old_mem = bo->resource is assigned.
As you can see on the alloc & free stack calls, on the same function amdgpu_bo_move,
amdgpu_move_blit in the end frees bo->resource at ttm_bo_move_accel_cleanup with ttm_bo_wait_free_node(bo, man->use_tt).
But amdgpu_bo_move continues after that, reaching trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type) at the end, causing the use-after-free bug.
Steps to reproduce are as below.
union drm_amdgpu_gem_create *arg1;
arg1 = malloc(sizeof(union drm_amdgpu_gem_create));
arg1->in.bo_size = 0x8;
arg1->in.alignment = 0x0;
arg1->in.domains = 0x4;
arg1->in.domain_flags = 0x9;
ioctl(fd, 0xc0206440, arg1);
arg1->in.bo_size = 0x7fffffff;
arg1->in.alignment = 0x0;
arg1->in.domains = 0x4;
arg1->in.domain_flags = 0x9;
ioctl(fd, 0xc0206440, arg1);
The KASAN report is as follows:
==================================================================
BUG: KASAN: slab-use-after-free in amdgpu_bo_move+0x1479/0x1550
Read of size 4 at addr ffff88800f5bee80 by task syz-executor/219
Call Trace:
<TASK>
amdgpu_bo_move+0x1479/0x1550
ttm_bo_handle_move_mem+0x4d0/0x700
ttm_mem_evict_first+0x945/0x1230
ttm_bo_mem_space+0x6c7/0x940
ttm_bo_validate+0x286/0x650
ttm_bo_init_reserved+0x34c/0x490
amdgpu_bo_create+0x94b/0x1610
amdgpu_bo_create_user+0xa3/0x130
amdgpu_gem_create_ioctl+0x4bc/0xc10
drm_ioctl_kernel+0x300/0x410
drm_ioctl+0x648/0xb30
amdgpu_drm_ioctl+0xc8/0x160
</TASK>
Allocated by task 219:
kmalloc_trace+0x211/0x390
amdgpu_vram_mgr_new+0x1d6/0xbe0
ttm_resource_alloc+0xfd/0x1e0
ttm_bo_mem_space+0x255/0x940
ttm_bo_validate+0x286/0x650
ttm_bo_init_reserved+0x34c/0x490
amdgpu_bo_create+0x94b/0x1610
amdgpu_bo_create_user+0xa3/0x130
amdgpu_gem_create_ioctl+0x4bc/0xc10
drm_ioctl_kernel+0x300/0x410
drm_ioctl+0x648/0xb30
amdgpu_drm_ioctl+0xc8/0x160
Freed by task 219:
kfree+0x111/0x2d0
ttm_resource_free+0x17e/0x1e0
ttm_bo_move_accel_cleanup+0x77e/0x9b0
amdgpu_move_blit+0x3db/0x670
amdgpu_bo_move+0xfa2/0x1550
ttm_bo_handle_move_mem+0x4d0/0x700
ttm_mem_evict_first+0x945/0x1230
ttm_bo_mem_space+0x6c7/0x940
ttm_bo_validate+0x286/0x650
ttm_bo_init_reserved+0x34c/0x490
amdgpu_bo_create+0x94b/0x1610
amdgpu_bo_create_user+0xa3/0x130
amdgpu_gem_create_ioctl+0x4bc/0xc10
drm_ioctl_kernel+0x300/0x410
drm_ioctl+0x648/0xb30
amdgpu_drm_ioctl+0xc8/0x160
The buggy address belongs to the object at ffff88800f5bee70
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 16 bytes inside of
freed 96-byte region [ffff88800f5bee70, ffff88800f5beed0)
Should you need any more information, please do not hesitate to contact us.
Best regards,
Joonkyo Jung
