CVE-2019-1125: Spectre SWAPGS gadget vulnerability

Updated -


Red Hat has been made aware of an additional spectre-V1 like attack vector, requiring updates to the Linux kernel. This additional attack vector builds on existing software fixes shipped in previous kernel updates. This vulnerability only applies to x86-64 systems using either Intel or AMD processors.

This issue has been assigned CVE-2019-1125 and is rated Moderate.

An unprivileged local attacker can use these flaws to bypass conventional memory security restrictions to gain read access to privileged memory that would otherwise be inaccessible.


The vulnerability dubbed “Spectre” affected microprocessors that performed branch prediction as a method of improving system performance when evaluating complex instruction paths run by the CPU. These processors would speculate on the most likely choice when presented with a series of choices. These choices could act on private data and bring this data into cache. A careful observer of access times could use the timing of these actions to infer the contents of the speculatively accessed memory by observing timing results (commonly referred to as a timing attack).

The x86 family of microprocessors implements a feature known as memory “segmentation” in which all memory addresses are formed from a segment base address, plus an offset within that segment. The architecture defines segment registers (CS, DS, SS, ES, FS, GS) that may be used in building a complete memory address, with some used implicitly by certain instructions.

The “FS” and “GS” registers can be used in 64-bit mode to provide an offset into memory ranges reserved for specific data. For example, Linux uses “GS” to store TLS (Thread Local Storage) pointers in userspace (user) applications, and to serve as an offset into per_cpu data for a given processor when in-kernel. The “SWAPGS” instruction is used on 64-bit entry into kernel code to swap the current user space value of “GS” with the value intended to be used during kernel operations.

This newly swapped “GS” value is used to perform accesses to kernel data, using the PER_CPU macros contained within the kernel. The “SWAPGS” instruction was added as part of the mechanism to transition from userspace to kernel space, which determines a convention to find kernel data such as kernel stack data.

The SWAPGS instruction is a primitive instruction and does not validate the correctness of the values it uses. There are cases where the system may enter kernel code but may not require the swap or may re-enter kernel mode when already running in kernel mode.

Due to these cases, there are checks within the kernel entry code where conditional branches test to determine if the swap is necessary. As a result, it is possible that these conditional branches in the Linux kernel entry code may mis-speculate into code that will not perform the SWAPGS, resulting in a window of speculative execution during which the wrong GS is used for dependent memory operations. A typical Spectre-style side-channel analysis may be performed on the timing results by a suitably skilled attacker.

Determine Vulnerability

The specific instruction of interest (SWAPGS) is only available on the x86-64 architecture, as such only x86-64 platform vendors (Intel and AMD) are known to be affected.


There is no known complete mitigation other than updating the kernel and rebooting the system. This kernel patch builds on existing spectre mitigations from previous updates.

Customers are advised to take a risk-based approach to mitigate this issue. Systems that require high degrees of security and trust should be addressed first and isolated from untrusted systems until treatments can be applied to those systems to reduce the risk of exploit.

Note that based on industry feedback, we are not aware of any known way to exploit this vulnerability on Linux kernel-based systems.

Affected Products

The following Red Hat product versions are impacted:

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Atomic Host
  • Red Hat Enterprise MRG 2
  • Red Hat OpenShift Online v3
  • Red Hat Virtualization (RHV/RHV-H)
  • Red Hat OpenStack Platform
  • Red Hat OpenShift Container Platform 4 (RHEL CoreOS)

While Red Hat's Linux Containers are not directly impacted by third-party hardware vulnerabilities, their security relies upon the integrity of the host kernel environment. Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers. To protect the privacy of the containers in use, you will need to ensure that the Container host (such as Red Hat Enterprise Linux, RHEL CoreOS or Atomic Host) has been updated against these attacks.


Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately and reboot to mitigate this flaw correctly.


Red Hat thanks Intel and industry partners for reporting this issue and collaborating on the mitigations for the same.

Frequently Asked Questions

Does the update need to be applied to both guests and hosts?
Yes, much like the original spectre v1, this can be used to create attacks across VMs.
Do I need to reboot after updating the kernel?
I have applied previous Spectre-v1 fixes do I need to apply this also?
What is the performance impact from this update?
The fix for this CVE has shown to cause a minimal performance impact. The impact will be felt more in applications with high rates of user-kernel-user space transitions. For example, in system calls, NMIs, and kernel interrupts.
Although there is no way to say what the impact will be for any given workload, in our testing we determined that the performance changes are not measurable in current benchmarks.
Can I disable this change with a kernel command line parameter?
This flaw is a spectre-v1 style flaw. The kernel can be booted with the “nospectre_v1” parameter to disable this family of mitigations.

Additional Information

Spectre Attacks: Exploiting Speculative Execution
Find out more about the Speculative Store Bypass, announced in May 2018.
What are Meltdown and Spectre? Here’s what you need to know.
Reading privileged memory with a side-channel
Deep Dive: Intel Analysis of Speculative Behavior of SWAPGS and Segment Registers