Information leak through outs instruction emulation
The emulation of the outs instruction for 64-bit PV guests uses an uninitialized variable as the segment base for the source data if an FS: or GS: segment override is used, and if the segment descriptor the respective non-null selector in the corresponding selector register points to cannot be read by the emulation code (this is possible if the segment register was loaded before a more recent GDT or LDT update, i.e. the segment register contains stale data).
A malicious guest might be able to get hold of contents of the hypervisor stack, through the fault address passed to the page fault handler if the outs raises such a fault (which is mostly under guest control). Other methods for indirectly deducing information also exist.
lack of check (invalid return value)
x86: check segment descriptor read result in 64-bit OUTS emulation
When emulating such an operation from a 64-bit context (CS has long mode set), and the data segment is overridden to FS/GS, the result of reading the overridden segment’s descriptor (readdescriptor) is not checked. If it fails, database is left uninitialized.
This can lead to 8 bytes of Xen’s stack being leaked to the guest (implicitly, i.e. via the address given in a #PF).
--- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1993,10 +1993,10 @@ static int emulate_privileged_op(struct break; } } - else - read_descriptor(data_sel, v, regs, - &data_base, &data_limit, &ar, - 0); + else if ( !read_descriptor(data_sel, v, regs, + &data_base, &data_limit, &ar, 0) || + !(ar & _SEGMENT_S) || !(ar & _SEGMENT_P) ) + goto fail; data_limit = ~0UL; ar = _SEGMENT_WR|_SEGMENT_S|_SEGMENT_DPL|_SEGMENT_P; }
A malicious 64-bit PV guest might conceivably gain access to sensitive data relating to other guests.