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 = 0x2000000000000;
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 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
Call Trace:
<TASK>
? 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
</TASK>
Should you need any more information, please do not hesitate to contact us.
Best regards,
Joonkyo Jung
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 = 0x2000000000000;
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 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
Call Trace:
<TASK>
? 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
</TASK>
Should you need any more information, please do not hesitate to contact us.
Best regards,
Joonkyo Jung
