GPU VulnDB

Database/Kernel, userspace & hypervisor

Intel x86-64 CPUs (Ivy Bridge onward); Windows and Linux kernel entry paths: The kernel's syscall/interrupt entry path

CVE-2019-1125Kernel, userspace & hypervisorSWAPGSSpectre v1 SWAPGS variantSpectre-SWAPGScurated

Impact

The kernel's syscall/interrupt entry path uses SWAPGS to switch the GS base between user and kernel values; the CPU speculates past the conditional that decides whether to swap, so a user process can make the kernel speculatively dereference a user-controlled GS base and leak kernel memory through a cache channel. It bypasses the standard Spectre v1 mitigations because it lives in the entry code that runs before them. Operator exposure is a local process reading kernel memory - which on a container host means other tenants' data in the page cache and the kernel's credential structures.

Who can reach it

Unprivileged local code on the host or inside a guest, exercised through ordinary syscalls and interrupts. No SMT or core-sharing requirement.

What to do

Kernel/hypervisor patch only - no microcode, no BIOS flash. The fix adds LFENCE serialization in the SWAPGS entry paths. Reboot into the patched kernel (drain the node), and that is the whole job. Runtime cost is a serializing instruction on kernel entry - measurable on syscall-microbenchmarks, effectively invisible on GPU workloads. Patched in Linux since 5.2 and backported everywhere, so on a current fleet this is closed; the audit item is confirming no host runs a pre-August-2019 kernel and that 'mitigations=off' is not set anywhere.

References

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.