Re: reject PRIME export without TTM backing

[Greg KH]

On Thu, Oct 29, 2026 at 04:33:15PM +0800, 潘煜杭 wrote:
> Hello,
> 
> GPT-5 assisted with the initial analysis and drafting the proposed fix. I am
> responsible for this report and patch.
> 
> While fuzzing the vmwgfx PRIME import path, I observed a kernel NULL pointer
> dereference in vmw_gem_object_get_sg_table(). The userspace operation was
> DRM_IOCTL_PRIME_FD_TO_HANDLE. The call path was:
> 
>   __x64_sys_ioctl()
>     -> vmw_unlocked_ioctl()
>     -> vmw_generic_ioctl()
>     -> drm_ioctl()
>     -> drm_prime_fd_to_handle_ioctl()
>     -> vmw_prime_fd_to_handle()
>     -> drm_gem_prime_fd_to_handle()
>     -> drm_gem_prime_import_dev()
>     -> dma_buf_map_attachment()
>     -> drm_gem_map_dma_buf()
>     -> vmw_gem_object_get_sg_table()
> 
> The vmwgfx callback obtains the TTM buffer object and uses bo->ttm as the
> embedded dma_ttm member of struct vmw_ttm_tt. In the crashing path, bo->ttm
> was NULL. container_of() consequently produced a NULL-based vmw_ttm_tt
> pointer, and reading vmw_tt->vsgt.sgt faulted at offset 0x88:
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000088
>   RIP: 0010:vmw_gem_object_get_sg_table+0x2f/0xa0
>   RBP: 0000000000000000
>   CR2: 0000000000000088
> 
> The faulting instruction reads from [RBP + 0x88]; with RBP equal to zero,
> this matches the reported address. The callback requires a vmwgfx TTM
> translation table, so it must reject an object without bo->ttm before
> container_of() and member access. This patch returns -EINVAL in that case.
> 
> The patch below is against the Linux 7.3 source tree; it
> applies cleanly and passes checkpatch.pl --strict.
> 
> Assisted-by: OpenAI Codex (GPT-5)
> Signed-off-by: Yuhang Pan <242270054@xxxxxxxxxx>

No Fixes: or cc: stable tags?

thanks,

greg k-h