On 2026/9/8 20:34, [email protected] wrote: > [Severity: High] > This is another pre-existing issue, but is it possible for > virtio_gpu_fence_alloc() to fail and cause a NULL pointer dereference > earlier in the submission path? > > Looking at virtio_gpu_init_submit() called earlier in this ioctl, it does > not check the return value of virtio_gpu_fence_alloc(): > > drivers/gpu/drm/virtio/virtgpu_submit.c:virtio_gpu_init_submit() { > ... > out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_idx); > else > out_fence = NULL; > > if (drm_fence_event) { > err = virtio_gpu_fence_event_create(dev, file, out_fence, ring_idx); > ... > } > > And in virtio_gpu_fence_event_create(): > > drivers/gpu/drm/virtio/virtgpu_submit.c:virtio_gpu_fence_event_create() { > ... > fence->e = e; > ... > } > > If kzalloc_obj() inside virtio_gpu_fence_alloc() fails due to memory pressure, > it returns NULL, which is then unconditionally dereferenced. > > Can unprivileged userspace trigger this by invoking the execbuffer ioctl > under constrained memory conditions? >
Our fuzzing results confirm this NULL pointer deref path is valid. Will send a patch soon.
