POP SS debug exception - CVE-2018-8897 [Moderate] & CVE-2018-1087 [Important]

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.

Background Information

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.

Acknowledgements

Red Hat would like to thank Nick Peterson of Everdox Tech LLC for reporting CVE-2018-8897.
Red Hat would like to thank Andy Lutomirski for reporting CVE-2018-1087.

Impacted Products

Red Hat Product Security has rated the kernel issue (CVE-2018-8897) as having a security impact of Moderate.

Red Hat Product Security has rated the KVM issue (CVE-2018-1087) as having security impact of Important.

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

Attack Description

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.