CVE-2012-0218
guest denial of service on syscall/sysenter exception generation
When guest user code running inside a Xen guest operating system attempts to execute a syscall or sysenter instruction, but when the guest operating system has not registered a handler for that instruction, a General Protection Fault may need to be injected into the guest.
It has been discovered that the code in Xen which does this fails to clear a flag requesting exception injection, with the result that a future exception taken by the guest and handled entirely inside Xen will also be injected into the guest despite Xen having handled it already, probably crashing the guest.
logic error (not clear flag)
http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/0fec1afa4638
x86-64: fix #GP generation in assembly code
When guest use of sysenter (64-bit PV guest) or syscall (32-bit PV guest) gets converted into a GP fault (due to no callback having got registered), we must
- honor the GP fault handler’s request the keep enabled or mask event delivery
- not allow TBF_EXCEPTION to remain set past the generation of the (guest) exception in the vCPU’s trap_bounce.flags, as that would otherwise allow for the next exception occurring in guest mode, should it happen to get handled in Xen itself, to nevertheless get bounced to the guest kernel.
Also, just like compat mode syscall handling already did, native mode sysenter handling should, when converting to #GP, subtract 2 from the RIP present in the frame so that the guest’s GP fault handler would see the fault pointing to the offending instruction instead of past it.
Finally, since those exception generating code blocks needed to be modified anyway, convert them to make use of UNLIKELY_{START,END}().
User space processes on some guest operating systems may be able to crash the guest.
guest DoS