aboutsummaryrefslogtreecommitdiff
path: root/lib/mpi/mpiutil.c
diff options
context:
space:
mode:
authorDaniel Vetter <[email protected]>2020-02-02 14:21:33 +0100
committerDaniel Vetter <[email protected]>2020-02-06 19:04:41 +0100
commit4b848f20eda5974020f043ca14bacf7a7e634fc8 (patch)
treecb8133c9dd80bcb546a363c455bd59e46fdea65b /lib/mpi/mpiutil.c
parentdb735fc4036bbe1fbe606819b5f0ff26cc76cdff (diff)
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 <[email protected]> Cc: Hillf Danton <[email protected]> Reported-by: [email protected] Cc: [email protected] Cc: Emil Velikov <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Rob Clark <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'lib/mpi/mpiutil.c')
0 files changed, 0 insertions, 0 deletions