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 
-            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;


A malicious 64-bit PV guest might conceivably gain access to sensitive data relating to other guests.

information leak