NULL ptr dereference in i915_gem_alloc_object()

[Daniel Vetter]

On Sun, Jan 19, 2014 at 2:28 AM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> Testing running out of file descriptors shows a NULL pointer
> dereference in i915_gem_alloc_object() because base.filp ends up being
> NULL. So the line
>
>     mapping = file_inode(obj->base.filp)->i_mapping;
>
> will cause an oops. The call chain is
>
> SyS_ioctl ->
>   do_vfs_ioctl ->
>     drm_ioctl ->
>       i915_gem_create_ioctl ->
>         i915_gem_create ->
>           i915_gem_alloc_object
>
> Now, some functions do test "base.filp" for NULL (see for example
> i915_gem_pread_ioctl()) so clearly people know that the filp may not
> exist. But that path does not.

This is unrelated since only shmem backed objects (should) have
base.filp set, but other gem objects (backed by stolen mem or from
dma-buf) don't have that. A bunch of gem ioclts aren't supported with
these special objects (like pread/pwrite) and so we check for that and
bail out.

> Comments? Patches even?

If we fail to allocate the shmem file drm_gem_object_init should fail
and i915_gem_alloc_object should bail out early. Apparently that
doesn't work as it should. On a quick check it's not the lack of
_OR_NULL in drm_gem_object_init so I'm not really sure what's going on
here. I'll try to reproduce this here meanwhile.

Adding dri-devel since other gem drivers should be equally affected.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch