Red Hat has been made aware of a flaw in the way the Linux kernel handles exceptions triggered after the POP SS and MOV to SS instructions. These issues could lead to denial of service for unpatched systems.
These instructions hold delivery of interrupts, data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction. Separate issues are identified as related to the Linux kernel and KVM technologies.
Modern processors provide debugging infrastructure, used by system designers and application developers to debug their software. It includes set of debug registers (DR0...DR7) and other Machine Specific Registers (MSRs). A user can configure these registers to monitor events, including memory access (read or write), instruction execution and I/O port access. When such an event occurs during program execution, the processor raises a Debug Exception (#DB) to transfer execution control to debugging software (for example, gdb). This catches the debug exception and allows a developer to examine program execution state. For example, to monitor read/write memory access at address ‘0x4007c7’, the user stores address ‘0x4007c7’ in one of the debug registers DR0...DR3, and the processor raises #DB when memory location ‘0x4007c7’ is accessed during program execution. Such addressing in the debug register is called Breakpoint.
Mov %DR0, 0x4007c7
Generally, exceptions are raised at the instruction boundary; all instructions before the one causing the exception are allowed to complete and the one causing the exception is stalled, so that it can resume execution once the exception has been handled. In a few instances where the instruction causes a task switch or stack switch, these exceptions are raised after the instruction; notably, the instruction causing the exception is allowed to complete, as happens with MOV SS or POP SS.
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 Atomic Host
- Red Hat Enterprise MRG 2
- Red Hat Virtualization Hypervisor 4
- Red Hat Enterprise Virtualization Hypervisor 3
Typical stack switching involves two operations: one to load the stack segment selector (SS) register, and another to set the stack pointer register (RSP), for example:
Mov SS, [RAX]
Mov RSP, RBP
When switching stack via MOV SS (OR POP SS) instructions as depicted above, the processor stalls delivery of all interrupts and debug exceptions (#DB). This is due to the fact that if an exception were to occur after the Segment Selector (SS) register had been loaded (but before the Stack Pointer (RSP) registers is positioned properly), the interrupt handler would see an invalid stack state. Thus, the processor delivers pending interrupts and/or debug exceptions after the first instruction following when the stack switch is executed.
Now consider that a Breakpoint was set on the memory location ([RAX] above) accessed by the Mov SS instruction during the stack switch. This Breakpoint will generate a Breakpoint Exception (#BP) after the stack switch. Now if the first instruction after the stack switch happens to be one which changes the current privilege level (CPL < 3), like SYSCALL, SYSENTER, INT3 etc., then the delayed Breakpoint Exception (#BP) from above is delivered in the kernel space, thus potentially resulting in privilege escalation.For the Linux kernel's KVM hypervisor, during the stack switch operation, the processor did not deliver interrupts and exceptions, rather they are delivered once the first instruction after the stack switch is executed. An unprivileged KVM guest user could use this flaw to crash the guest or, potentially, escalate their privileges in the guest.
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.
Updates for Affected Products
|Red Hat Enterprise Linux 7 (z-stream)||kernel||RHSA-2018: 1318|
|Red Hat Enterprise Linux 7||kernel-rt||RHSA-2018: 1355|
|Red Hat Enterprise Linux 7.4 Extended Update Support**||kernel||RHSA-2018: 1345|
|Red Hat Enterprise Linux 7.3 Extended Update Support**||kernel||RHSA-2018: 1348|
|Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support***,****||kernel||RHSA-2018: 1347|
|Red Hat Enterprise Linux 6 (z-stream)||kernel||RHSA-2018: 1319|
|Red Hat Enterprise Linux 6.7 Extended Update Support**||kernel||RHSA-2018: 1346|
|Red Hat Enterprise Linux 6.6 Advanced Update Support***,****||kernel||RHSA-2018: 1351|
|Red Hat Enterprise Linux 6.5 Advanced Update Support***||kernel||RHSA-2018: 1350|
|Red Hat Enterprise Linux 6.4 Advanced Update Support***||kernel||RHSA-2018: 1349|
|Red Hat Enterprise Linux 5 Extended Lifecycle Support*||kernel||RHSA-2018: 1353|
|Red Hat Enterprise Linux 5.9 Advanced Update Support***||kernel||RHSA-2018: 1352|
|RHEL Atomic Host||kernel||respun|
|Red Hat Enterprise MRG 2||kernel-rt||RHSA-2018: 1354|
|Red Hat Virtualization 4||redhat-virtualization-host||RHSA-2018: 1710|
|Red Hat Enterprise Virtualization 3 Extended Lifecycle Support*||rhev-hypervisor7||RHSA-2018: 1711|
*An active ELS subscription is required for access to this patch. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.
**An active EUS subscription is required for access to this patch. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.
***An active AUS subscription is required for access to this patch in RHEL AUS.
****An active TUS subscription is required for access to this patch in RHEL TUS.
While Red Hat's Linux Containers are not directly impacted by kernel issues, 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 containers in use, you will need to ensure that the Container host has been updated against these attacks. Red Hat has released an updated Atomic Host for this use case.
There is no known mitigation, other than applying vendor software updates.
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.