Skip to content
  • Andrew Cooper's avatar
    xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests. · 9174adbe
    Andrew Cooper authored
    This fixes CVE-2013-0190 / XSA-40
    
    There has been an error on the xen_failsafe_callback path for failed
    iret, which causes the stack pointer to be wrong when entering the
    iret_exc error path.  This can result in the kernel crashing.
    
    In the classic kernel case, the relevant code looked a little like:
    
            popl %eax      # Error code from hypervisor
            jz 5f
            addl $16,%esp
            jmp iret_exc   # Hypervisor said iret fault
    5:      addl $16,%esp
                           # Hypervisor said segment selector fault
    
    Here, there are two identical addls on either option of a branch which
    appears to have been optimised by hoisting it above the jz, and
    converting it to an lea, which leaves the flags register unaffected.
    
    In the PVOPS case, the code looks like:
    
            popl_cfi %eax         # Error from the hypervisor
            lea 16(%esp),%esp     # Add $16 before choosing fault path
            CFI_ADJUST_CFA_OFFSET -16
            jz 5f
            addl $16,%esp         # Incorrectly adjust %esp again
            jmp iret_exc
    
    It is possible unprivileged userspace applications to cause this
    behaviour, for example by loading an LDT code selector, then changing
    the code selector to be not-present.  At this point, there is a race
    condition where it is possible for the hypervisor to return back to
    userspace from an interrupt, fault on its own iret, and inject a
    failsafe_callback into the kernel.
    
    This bug has been present since the introduction of Xen PVOPS support
    in commit 5ead97c8
    
     (xen: Core Xen implementation), in 2.6.23.
    
    Signed-off-by: default avatarFrediano Ziglio <frediano.ziglio@citrix.com>
    Signed-off-by: default avatarAndrew Cooper <andrew.cooper3@citrix.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    9174adbe