Linux kernel (drivers/gpu/drm/xe): The observation-config ioctl dereferences the config object after releasing the lock

Impact

The observation-config ioctl dereferences the config object after releasing the lock that guards its lifetime, so a second thread that guesses the freshly allocated config id and removes it wins the race and frees the object mid-use. The upstream description names the attacker explicitly - this is a deliberate ioctl-versus-ioctl race producing a kernel use-after-free.

Who can reach it

A tenant process holding /dev/dri/renderD* on an Intel xe GPU runs add-config and remove-config in two threads, guessing the id. Reachability is conditional on the container being able to use the xe observation/OA ioctls, which normally means CAP_PERFMON inside the container or a relaxed perf_stream_paranoid setting - if you hand tenants profiling access to the GPU, they have it.

What to do

Boot a kernel carrying the xe_oa locking fix below. Interim: do not grant CAP_PERFMON to tenant containers, keep kernel.perf_event_paranoid/xe observation defaults strict, and drop GPU profiling access for untrusted workloads.

References