GPU VulnDB

Database/Firmware, BMC & network fabric

AMD erratum #1718: INVLPGB/TLBSYNC may fail to invalidate a TLB entry

CVSS 7.8CVE-2026-99099Firmware, BMC & network fabriccurated

Impact

On affected AMD processors an INVLPGB/TLBSYNC pair can leave a TLB entry valid after the kernel believes it has been flushed. A stale translation means a core can keep reading or writing a physical page that has already been unmapped and reused, which is a memory-corruption and cross-process information-disclosure primitive rather than a crash bug. On a GPU node this lands under every tenant on the box: broadcast TLB invalidation is used by the host kernel and by KVM, so the stale mapping is not confined to the process that triggered it. The kernel now detects the erratum and applies a software workaround where no microcode fix is present; the record does not state which CPU models are affected, so check the AMD erratum list for your parts.

Who can reach it

Local. Any code running on an affected AMD host - including an unprivileged process or a guest VM - can be in a position to observe or exploit the missed invalidation; no authentication beyond the ability to execute code on the node is needed.

What to do

Install a kernel carrying the erratum detection and software workaround (the three git.kernel.org commits) and reboot each affected AMD node; where AMD ships a microcode fix for your model, apply it through the BIOS or the microcode loader, which also requires a reboot to take effect reliably. No runtime mitigation exists - the workaround is in the kernel's invalidation path. Budget a full rolling drain and reboot of the AMD-based part of the fleet.

References

Related entries

All Firmware, BMC & network fabric 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.