Re: Reporting a slab-use-after-free in amdgpu
Hi, Thank you for patching two of the bugs we have reported! I was just wondering if there's any news on the one other bug we have reported: BUG: KASAN: slab-use-after-free in amdgpu_bo_move+0x1479/0x1550. I see that there is a gitlab issue( https://gitlab.freedesktop.org/drm/amd/-/issues/3171) created for this bug, and there also is a patch( https://lists.freedesktop.org/archives/amd-gfx/2024-March/105680.html) that Christian made for this. Though, it seems that the issue is not resolved yet, and the patch is not yet pushed to mainstream branches. So I was wondering, do you have any plans for pushing this patch? If so, would it be possible for us to get a Reported-by tag on the patch? Best, Joonkyo On Fri, Mar 8, 2024 at 4:32 PM Joonkyo Jung wrote: > Hi Vitaly, > > No worries, thank you for working on the patches! > > I have also confirmed that with the inflight patch, issue No.1 > (use-after-free) seems to be resolved. > However, I have reproduced issue No.3 (slab-use-after-free) even with the > patch for issue No.1 applied - if it's the first program tested after > reboot. > (i.e., if any other bugs are tested before the slab-use-after-free, it > does not reproduce). > > Could you check if the bug reproduces in this condition for you too? > I will check and see why this is happening and update you if I have > something new. > > Thank you! > > Best, > Joonkyo > > > > On Fri, Mar 8, 2024 at 12:45 PM vitaly prosyak wrote: > >> Hi Joonkyo, >> Sorry for the delay. >> Yes, sure, I reproduced issue 2 (null-ptr-deref in amdgpu) and I will >> provide the fix soon. >> However, issue No. 3 is no longer reproducible if the recent patch >> inflight is applied which fixes issue No 1. >> >> Do you see the same behavior? >> >> Thanks in advance, Vitaly >> On 2024-03-07 20:18, Joonkyo Jung wrote: >> >> 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 님이 작성: >> >>> 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 = 0x7fff; >>> 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 88800f5bee80 by task syz-executor/219 >>> Call Trace: >>> >>> 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 >>> >>> >>> Allocated by task 219: >>>
Re: Reporting a slab-use-after-free in amdgpu
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 님이 작성: > 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 = 0x7fff; > 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 88800f5bee80 by task syz-executor/219 > Call Trace: > > 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 > > > 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 88800f5bee70 > which belongs to the cache kmalloc-96 of size 96 > The buggy address is located 16 bytes inside of > freed 96-byte region [88800f5bee70, 88800f5beed0) > > Should you need any more information, please do not hesitate to contact us. > > Best regards, > Joonkyo Jung >
Re: Reporting a slab-use-after-free in amdgpu
Hi Vitaly, No worries, thank you for working on the patches! I have also confirmed that with the inflight patch, issue No.1 (use-after-free) seems to be resolved. However, I have reproduced issue No.3 (slab-use-after-free) even with the patch for issue No.1 applied - if it's the first program tested after reboot. (i.e., if any other bugs are tested before the slab-use-after-free, it does not reproduce). Could you check if the bug reproduces in this condition for you too? I will check and see why this is happening and update you if I have something new. Thank you! Best, Joonkyo On Fri, Mar 8, 2024 at 12:45 PM vitaly prosyak wrote: > Hi Joonkyo, > Sorry for the delay. > Yes, sure, I reproduced issue 2 (null-ptr-deref in amdgpu) and I will > provide the fix soon. > However, issue No. 3 is no longer reproducible if the recent patch > inflight is applied which fixes issue No 1. > > Do you see the same behavior? > > Thanks in advance, Vitaly > On 2024-03-07 20:18, Joonkyo Jung wrote: > > 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 님이 작성: > >> 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 = 0x7fff; >> 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 88800f5bee80 by task syz-executor/219 >> Call Trace: >> >> 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 >> >> >> 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 88800f5bee70 >> which belongs to the cache kmalloc-96 of size 96 >> The buggy address is located 16 bytes inside of >> freed 96-byte region [88800f5bee70, 88800f5beed0) >> >> Should you need any more information, please do not hesitate to contact >> us. >> >> Best regards, >> Joonkyo Jung >> >
Re: Reporting a use-after-free in amdgpu and null-ptr-deref
Could you provide details of your system? > > Much appreciated for your responce. > > Vitaly > > > I placed your findings below to keep the context and track the issues. > > > === > > Reporting a slab-use-after-free in amdgpu.eml > > Subject: > Reporting a slab-use-after-free in amdgpu > > From: > Joonkyo Jung > > Date: > 2024-02-16, 04:22 > > To: > alexander.deuc...@amd.com, christian.koe...@amd.com, xinhui@amd.com > > CC: > amd-gfx@lists.freedesktop.org, Dokyung Song > , jisoo.j...@yonsei.ac.kr, yw9...@yonsei.ac.kr > > 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 = 0x7fff; > 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 88800f5bee80 by task syz-executor/219 > Call Trace: > > 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 > > > 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 88800f5bee70 > which belongs to the cache kmalloc-96 of size 96 > The buggy address is located 16 bytes inside of > freed 96-byte region [88800f5bee70, 88800f5beed0) > > Should you need any more information, please do not hesitate to contact us. > > Best regards, > Joonkyo Jung > > Reporting a null-ptr-deref in amdgpu.eml > > Subject: > Reporting a null-ptr-deref in amdgpu > > From: > Joonkyo Jung > > Date: > 2024-02-16, 04:20 > > To: > alexander.deuc...@amd.com, christian.koe...@amd.com, xinhui@amd.com > > CC: > Dokyung Song , > jisoo.j...@yonsei.ac.kr, yw9...@yonsei.ac.kr, amd-gfx@lists.freedesktop.org > > Hello, > > We > would like to report a null-ptr-deref 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. > > The first ioctl amdgpu_ctx_ioctl will create a ctx, and return ctx_id = 1 to > the userspace. > Second >
Reporting a null-ptr-deref in amdgpu
Hello, We would like to report a null-ptr-deref 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. The first ioctl amdgpu_ctx_ioctl will create a ctx, and return ctx_id = 1 to the userspace. Second ioctl, actually any ioctl that will eventually call amdgpu_ctx_get_entity, carries this ctx_id and passes the context check. Here, for example, drm_amdgpu_wait_cs. Validations in amdgpu_ctx_get_entity can also be passed by the user-provided values from the ioctl arguments. This eventually leads to drm_sched_entity_init, where the null-ptr-deref will trigger on RCU_INIT_POINTER(entity->last_scheduled, NULL); Steps to reproduce are as below. union drm_amdgpu_ctx *arg1; union drm_amdgpu_wait_cs *arg2; arg1 = malloc(sizeof(union drm_amdgpu_ctx)); arg2 = malloc(sizeof(union drm_amdgpu_wait_cs)); arg1->in.op = 0x1; ioctl(AMDGPU_renderD128_DEVICE_FILE, 0x140106442, arg1); arg2->in.handle = 0x0; arg2->in.timeout = 0x2; arg2->in.ip_type = 0x9; arg2->in.ip_instance = 0x0; arg2->in.ring = 0x0; arg2->in.ctx_id = 0x1; ioctl(AMDGPU_renderD128_DEVICE_FILE, 0xc0206449, arg2); The KASAN report is as follows: general protection fault, probably for non-canonical address 0xdc05: [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0028-0x002f] Call Trace: ? drm_sched_entity_init+0x16e/0x650 ? drm_sched_entity_init+0x208/0x650 amdgpu_ctx_get_entity+0x944/0xc30 amdgpu_cs_wait_ioctl+0x13d/0x3f0 drm_ioctl_kernel+0x300/0x410 drm_ioctl+0x648/0xb30 amdgpu_drm_ioctl+0xc8/0x160 Should you need any more information, please do not hesitate to contact us. Best regards, Joonkyo Jung
Reporting a slab-use-after-free in amdgpu
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 = 0x7fff; 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 88800f5bee80 by task syz-executor/219 Call Trace: 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 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 88800f5bee70 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 16 bytes inside of freed 96-byte region [88800f5bee70, 88800f5beed0) Should you need any more information, please do not hesitate to contact us. Best regards, Joonkyo Jung
