Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 561110 (CVE-2015-7311) - app-emulation/xen: libxl fails to honour readonly flag on disks with qemu-xen (XSA-142) (CVE-2015-7311)
Summary: app-emulation/xen: libxl fails to honour readonly flag on disks with qemu-xen...
Alias: CVE-2015-7311
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa cve]
Depends on: CVE-2015-8339
  Show dependency tree
Reported: 2015-09-22 10:50 UTC by Kristian Fiskerstrand (RETIRED)
Modified: 2016-04-05 07:01 UTC (History)
1 user (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 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-09-22 10:50:37 UTC
Xen Security Advisory XSA-142

        libxl fails to honour readonly flag on disks with qemu-xen


Callers of libxl can specify that a disk should be read-only to the
guest.  However, there is no code in libxl to pass this information to
qemu-xen (the upstream-based qemu); and indeed there is no way in qemu
to make a disk read-only.

The vulnerability is exploitable only via devices emulated by the
device model, not the parallel PV devices for supporting PVHVM.
Normally the PVHVM device unplug protocol renders the emulated devices
inaccessible early in boot.


Malicious guest administrators or (in some situations) users may be
able to write to supposedly read-only disk images.

CDROM devices (that is, devices specified to be presented to the guest
as CDROMs, regardless of the nature of the backing storage on the
host) are not affected.


Only systems using qemu-xen (rather than qemu-xen-traditional) as the
device model version are vulnerable.

Only systems using libxl or libxl-based toolstacks are vulnerable.
(This includes xl, and libvirt with the libxl driver.)

All versions of libxl which support qemu-xen are vulnerable.  The
affected code was introduced in Xen 4.1.

If the host and guest together usually support PVHVM, the issue is
exploitable only if the malicious guest administrator has control of
the guest kernel or guest kernel command line.


Switching to qemu-xen-traditional will avoid this vulnerability.
This can be done with
in the xl configuration file.

Using stub domain device models (which necessarily involves switching
to qemu-xen-traditional) will also avoid this vulnerability.
This can be done with
in the xl configuration file.

Either of these mitigations is liable to have other guest-visible
effects or even regressions.

It may be possible, depending on the configuration, to make the
underlying storage object readonly, or to make it reject writes.


There is no reasonable resolution because Qemu does not (at the time
of writing) support presenting a read-only block device to a guest as
a disk.

The attached patch corrects the weakness in the libxl code, by
rejecting the unsupported configurations, rather than allowing them to
run but with the device perhaps writeable by the guest.  Applying it
should increase confidence and avoid future configuration errors, but
will break affected configurations specifying read-only disk devices.

xsa142-4.6.patch                 Xen 4.6.x and later
xsa142-4.5.patch                 Xen 4.3.x to 4.5.x inclusive

$ sha256sum xsa142*.patch
9ec0649f39720bc692be03c87ebea0506d6ec574f339fc745e41b31643240124  xsa142-4.5.patch
65f01167bfc141048261f56b99ed9b48ec7ff6e98155454ced938a17ec20e7d1  xsa142-4.6.patch


This issue was discussed in public in the Red Hat bugzilla:


Thanks to Michael Young of Durham University for bring this problem to
our attention.
Comment 1 Yury German Gentoo Infrastructure gentoo-dev 2015-12-24 00:45:59 UTC
Setting to Depend on Bug 566842 for cleanup.
Comment 2 GLSAMaker/CVETool Bot gentoo-dev 2016-04-05 07:01:07 UTC
This issue was resolved and addressed in
 GLSA 201604-03 at
by GLSA coordinator Yury German (BlueKnight).