[Intel-gfx] NULL ptr dereference in i915_gem_alloc_object()
Daniel Vetter
daniel.vetter at ffwll.ch
Sun Jan 19 12:36:20 CET 2014
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
More information about the Intel-gfx
mailing list