Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 678472 (CVE-2019-8934) - <app-emulation/qemu-4.0.0: ppc64: sPAPR emulator leaks the host hardware identity
Summary: <app-emulation/qemu-4.0.0: ppc64: sPAPR emulator leaks the host hardware iden...
Alias: CVE-2019-8934
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B4 [noglsa cve]
Depends on:
Reported: 2019-02-21 08:25 UTC by Agostino Sarubbo
Modified: 2019-08-03 15:19 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2019-02-21 08:25:47 UTC
From ${URL} :

It was found that the KVM PPC64 emulator for the sPAPR machine leaks the host 
hardware identity to all running guests. The sPAPAR(hw/ppc/spapr.c) emulator 
populates the device tree for the guest with two fields "host-serial" and 
"host-model". The values for these fields are taken via hypervisor from the 
host device tree data exposed in "/proc/device-tree/system-id" and 
"/proc/device-tree/model" file respectively.

Upstream patch:

CVE-2019-8934 assigned via

@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Matthias Maier gentoo-dev 2019-04-08 03:01:49 UTC
Unfortunately, the upstream patch relies on quite a bit of code cleanup/reorganization that occurred after the release of 3.1.0.

We will have to wait for a maintenance release, or a patch sanctioned by upstream for 3.1.0.

In detail the changes in

  static void spapr_machine_3_1_class_options(MachineClass *mc)

require the following changes:

+    static GlobalProperty compat[] = {
+        { TYPE_SPAPR_MACHINE, "host-model", "passthrough" },
+        { TYPE_SPAPR_MACHINE, "host-serial", "passthrough" },
+    };
+    compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));

that rely on a massive code reorganization that introduced "compat_props_add" as a means of setting compat properties locally (superseeding SET_MACHINE_COMPAT). The old mechanism seems to have different implications with respect to the livetime of the struct, so I refrain from cooking up a backported patch.