Date: Tue, 15 Aug 2017 12:05:57 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
CC: Xen.org security team <security-team-members@....org>
Subject: Xen Security Advisory 229 (CVE-2017-12134) - linux: Fix Xen block
IO merge-ability calculation
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2017-12134 / XSA-229
linux: Fix Xen block IO merge-ability calculation
UPDATES IN VERSION 3
The block layer in Linux may choose to merge adjacent block IO requests.
When Linux is running as a Xen guest, the default merging algorithm is
replaced with a Xen-specific one. When Linux is running as an x86 PV
guest, some BIO's are erroneously merged, corrupting the data stream
to/from the block device.
This can result in incorrect access to an uncontrolled adjacent frame.
A buggy or malicious guest can cause Linux to read or write incorrect
memory when processing a block stream. This could leak information from
other guests in the system or from Xen itself, or be used to DoS or
escalate privilege within the system.
All x86 Xen systems using pvops Linux in a backend role (either as
dom0, or as a disk device driver domain) are affected. This includes
upstream Linux versions 2.6.37 and later. Systems using the older
classic-linux fork are not affected.
All PV x86 domains doing block IO on behalf of a guest, including dom0
and any PV driver domains, are vulnerable. (Any HVM driver domains
running are not vulnerable.) This includes Xen vbd backends such as
blkback, but also direct IO performed for the guest via eg qemu.
ARM systems are not affected.
The vulnerability is only exposed if the underlying block device has
request merging enabled. See Mitigation.
The vulnerability is only exposed to configurations which use grant
mapping as a transport mechanism for the block data. Configurations
which use exclusively grant copy are not vulnerable.
Disable bio merges on all relevant underlying backend block devices.
echo 2 > /sys/block/nvme0n1/queue/nomerges
This issue was discovered by Jan H. Schönherr of Amazon.
Applying the appropriate attached patch resolves this issue.
$ sha256sum xsa229*
DEPLOYMENT DURING EMBARGO
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Download attachment "xsa229.patch" of type "application/octet-stream" (2451 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.