diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2020-02-02 14:21:33 +0100 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2020-02-06 19:04:41 +0100 |
commit | 4b848f20eda5974020f043ca14bacf7a7e634fc8 (patch) | |
tree | cb8133c9dd80bcb546a363c455bd59e46fdea65b /net/wireless/chan.c | |
parent | drm/msm: Set dma maximum segment size for mdss (diff) | |
download | linux-4b848f20eda5974020f043ca14bacf7a7e634fc8.tar.xz linux-4b848f20eda5974020f043ca14bacf7a7e634fc8.zip |
drm/vgem: Close use-after-free race in vgem_gem_create
There's two references floating around here (for the object reference,
not the handle_count reference, that's a different thing):
- The temporary reference held by vgem_gem_create, acquired by
creating the object and released by calling
drm_gem_object_put_unlocked.
- The reference held by the object handle, created by
drm_gem_handle_create. This one generally outlives the function,
except if a 2nd thread races with a GEM_CLOSE ioctl call.
So usually everything is correct, except in that race case, where the
access to gem_object->size could be looking at freed data already.
Which again isn't a real problem (userspace shot its feet off already
with the race, we could return garbage), but maybe someone can exploit
this as an information leak.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Clark <robdclark@chromium.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch
Diffstat (limited to 'net/wireless/chan.c')
0 files changed, 0 insertions, 0 deletions