GPU VulnDB

Database/NVIDIA / GPU stack

Linux drm/i915: execbuffer relocation cleanup frees past the exec array after command-parser VMAs

CVSS 7.8CVE-2026-99006NVIDIA / GPU stackcurated

Impact

In eb_relocate_parse_slow(), eb_parse() appends up to two VMAs and increments eb->buffer_count, and the error path then walks that inflated count while kvfree()ing relocation pointers taken from the exec object array. The cleanup therefore reads relocation pointers from entries that are VMAs, not exec objects, and passes them to kvfree() - freeing addresses an attacker partially controls through the submitted exec list. On an Intel Data Center GPU node, any local process holding a render node can reach the execbuffer ioctl, so the plausible outcome is kernel memory corruption from an unprivileged local context, with a kernel crash the cheap case. The fix pins the cleanup to the original exec object count.

Who can reach it

Local user or container with an Intel GPU render node (/dev/dri/renderD*) submitting an execbuffer with relocations and a command-parser path; on a shared node that is any tenant handed an Intel GPU. No authentication beyond device access, and no remote path.

What to do

Update to the fixed stable kernel (five stable commits in the record, cherry-picked from 2a0158925fb9) and reboot each node with Intel graphics or Intel Data Center GPUs. Until then the only mitigation is withholding /dev/dri render-node access from untrusted workloads; nodes with no i915 device loaded are unaffected.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-99006https://git.kernel.org/stable/c/152fb5083b9333a1cb8629572f9e0f276a404ba6https://git.kernel.org/stable/c/24c04e80c35ff36947366f6deafddb522eea080chttps://git.kernel.org/stable/c/72d5cbb10d4916a3f8ef9da516c5c0634aca8439

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.