Linux kernel i915: userspace-controlled parallel submit slot index lacks a Spectre-v1 nospec guard

Impact

The i915 GEM context-creation path uses a parallel-submission slot index taken straight from userspace without an array_index_nospec() barrier, so the CPU can speculatively index past the bounds check and leave a measurable trace. That gives a local caller a speculative out-of-bounds read gadget inside the GPU driver. It only matters where an i915 render node is actually reachable by untrusted code: Intel Data Center GPU Flex/Max fleets, or nodes that pass the onboard Intel graphics device into containers. On a typical headless NVIDIA or AMD GPU node, i915 is either not loaded or its /dev/dri nodes are not exposed to tenants, and the bug is then unreachable. The record reports a static-analysis finding confirmed by Intel Product Security, with no demonstrated leak.

Who can reach it

Local user or container holding an open handle on an i915 /dev/dri render node, issuing a context-create ioctl. No authentication beyond filesystem access to the device node; not reachable over the network.

What to do

Update to a stable kernel carrying the listed commits and reboot the node. Until then, the practical mitigation is access control rather than a patch: confirm whether i915 render nodes are exposed to tenant containers at all, and stop exposing them if nothing needs them. The record names no fixed release number beyond the stable commits.

References