On Sun, Jan 19, 2014 at 2:28 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
