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.