Linux i915 GPU kernel driver (GTT TLB handling): Stale GPU TLB entries let the GPU keep reading physical pages after

Impact

Stale GPU TLB entries let the GPU keep reading physical pages after they were unmapped and handed to somebody else. A tenant running crafted GPU code reads whatever the host recycled those pages into - other tenants' data, or kernel memory. This is a true cross-tenant memory disclosure on Intel GPU nodes, not a crash bug.

Who can reach it

Any local user or container with a DRM render node - i.e. any tenant that was scheduled a GPU. No privileged capability needed.

What to do

Update the kernel and reboot; the fix forces a full TLB flush on unbind, which costs GPU unbind throughput on memory-churning workloads. Drain the node - the driver cannot be swapped under live GPU jobs. Kernel-only, no firmware or microcode.

References

Related entries

• Linux kernel (pipe): Dirty Pipe: uninitialised pipe_buffer flags allow overwriting read-only files, inclCVE-2022-0847 · Linux kernel (pipe)High
• Linux kernel: out-of-bounds write in watch_queue filters lets a local user gain rootCVE-2022-0995 · Linux kernel watch_queue event notification subsystem (filter handling)High
• Linux kernel io_uring: missing work_flags identity types cause bad refcounts and a double freeCVE-2022-2327 · Linux kernel io_uring (per-operation identity reference counting)High
• Linux kernel (net/sched cls_route): Use-after-free in the cls_route filterCVE-2022-2588 · Linux kernel (net/sched cls_route)High
• Xen on AMD-Vi - unity map handling on device reassignment: AMD-Vi unity mappings are not correctly torn down orCVE-2022-26358 · Xen on AMD-Vi - unity map handling on device reassignmentHigh
• Xen on AMD-Vi - unity map handling: Second XSA-400 AMD-Vi unity-map issue. Stale or incorrect IOMMU mappings acrossCVE-2022-26359 · Xen on AMD-Vi - unity map handlingHigh