Linux drm/amdgpu gfx6: compute queues missed PFP sync, letting a submission run against stale state

CVSS 8.8CVE-2026-90286NVIDIA / GPU stackcurated

Impact

On GFX6 AMD parts the compute rings share the graphics command-processor path, but the driver treated register writes, pipeline-sync fence waits and post-VM-flush synchronization as if compute queues had no PFP. The prefetch parser could begin executing the next submission while the ME was still in the previous one, and VM flushes were not followed by PFP_SYNC_ME on compute queues - a submission can therefore run against stale register and page-table state, which is the shape of bug that produces cross-context memory access or GPU hangs. Practically this is narrow for a datacenter: GFX6 is Southern Islands-era hardware, not the CDNA/Instinct parts a modern GPU fleet runs, so most operators are unaffected. Where such cards are still in service, a wedged GPU means draining the node to reset it.

Who can reach it

Local user with access to the GPU device nodes - any tenant able to submit compute work to an affected GFX6 AMD GPU. No special privilege beyond render-node access. Requires GFX6-class hardware.

What to do

Pick up the stable kernel with the amdgpu fix and reboot the affected nodes; the driver change cannot be applied to a running kernel, so plan a drain and reboot. Operators with no GFX6-generation AMD GPUs in the fleet can treat this as not applicable.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-90286 https://git.kernel.org/stable/c/e1d3018e3621c90cec070b6915836ae129656663 https://git.kernel.org/stable/c/b5d1d3e4519dc8f1b55d6b236848bed67b11a2e8

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.