The QEMU model of the RTL8139 network card did not sufficiently validate inputs in the C+ mode offload emulation. This results in uninitialised memory from the QEMU process's heap being leaked to the domain as well as to the network.
A guest may be able to read sensitive host-level data relating to itself which resides in the QEMU process. Such information may include things such as information relating to real devices backing emulated devices or passwords which the host administrator does not intend to share with the guest admin.
All Xen systems running x86 HVM guests without stubdomains which have been configured with an emulated RTL8139 driver model (which is the default) are vulnerable. Systems using qemu-dm stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Both the traditional ("qemu-xen-traditional") or upstream-based ("qemu-xen") qemu device models are potentially vulnerable. Systems running only PV guests are NOT vulnerable. ARM systems are NOT vulnerable. QEMU-XEN-TRADITIONAL The patches supplied by the Qemu Project are of course against recent versions of qemu. They cannot be applied directly to qemu-xen-traditional. The Xen Project Security Team do not feel we have the resources to backport and qualify these substantial and intrusive patches. Users using qemu-xen-traditional with stub domains are not vulnerable, because the stub dm is a deprivileged qemu guest instance. Users using qemu-xen-traditional for compatibility with old guests can avoid the vulnerability by switching to using a stub device model. The Xen Project Security Team encourages users and downstreams who are using qemu-xen-traditional and able to backport the patches to share those patches with us, so that we may distribute them with an updated advisory. We will encourage the community to have a conversation, when this advisory is released, about the continuing security support status of qemu-xen-traditional in non-stub-dm configurations.