Xen Security Advisory 229 (CVE-2017-12134) - linux: Fix Xen block IO merge-ability calculation
Xen.org security team <[email protected]>
| Newsgroups | gmane.comp.emulators.xen.announce |
|---|---|
| Message-ID | <E1dhabd-0006gl-Oo__41135.511492803$1502799178$gmane$org@xenbits.xenproject.org> |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2017-12134 / XSA-229
version 3
linux: Fix Xen block IO merge-ability calculation
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
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.
IMPACT
======
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.
VULNERABLE SYSTEMS
==================
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.
MITIGATION
==========
Disable bio merges on all relevant underlying backend block devices.
For example,
echo 2 > /sys/block/nvme0n1/queue/nomerges
CREDITS
=======
This issue was discovered by Jan H. Schönherr of Amazon.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa229.patch Linux
$ sha256sum xsa229*
5f96c72c8c5a971d52f5540475a3fc6f4fef2071ec772ef21392fdc238eda858 xsa229.patch
$
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
administrators.
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
Team.
(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:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJZkuNWAAoJEIP+FMlX6CvZBt4H/3tpKPBmzTaI5yKPdBf6wU7L
hjmKG6QROeWV+EX3wmmmRi+iG0M90hDYFCTmhdNY4sjCdDEFDMB1KM8XA/LwHlz2
3gX6TVKQ/cXQRJFhlWSZQUDDd5jPqZzDK7KnhS2DC+MjnKvnnuS6N2ibIfaHJmUG
HL6VdS7GZ8Z434mgOZskWPFn5xeaWd1vXGV+GI9Ih2RRn/axe6l0RSzgDpfeGB3T
hVRQdy9wW4aXrnnUXEuuz5JNlTU1fuGXGz7W5BDP8mu9l/dzmDye6NOgVqo5wAkz
+l/fRbFrjdO9JnKDpASDjGuoOCZgkBBxmG2wUz8COi6JTA5X0IRysG5OMOYZ/KU=
=lyzV
-----END PGP SIGNATURE-----
_______________________________________________
Xen-announce mailing list
[email protected]
https://lists.xen.org/xen-announce
xsa229.patch
(application/octet-stream, 2.4 KB)
From 84882133e793299f685991e20a9631acfd0a5608 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne <[email protected]> Date: Tue, 18 Jul 2017 15:01:00 +0100 Subject: xen: fix bio vec merging MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current test for bio vec merging is not fully accurate and can be tricked into merging bios when certain grant combinations are used. The result of these malicious bio merges is a bio that extends past the memory page used by any of the originating bios. Take into account the following scenario, where a guest creates two grant references that point to the same mfn, ie: grant 1 -> mfn A, grant 2 -> mfn A. These references are then used in a PV block request, and mapped by the backend domain, thus obtaining two different pfns that point to the same mfn, pfn B -> mfn A, pfn C -> mfn A. If those grants happen to be used in two consecutive sectors of a disk IO operation becoming two different bios in the backend domain, the checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2 (they both point to the same mfn). However due to the bio merging, the backend domain will end up with a bio that expands past mfn A into mfn A + 1. Fix this by making sure the check in xen_biovec_phys_mergeable takes into account the offset and the length of the bio, this basically replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus addresses). While there also remove the usage of __BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers of xen_biovec_phys_mergeable. Reported-by: "Jan H. Schönherr" <[email protected]> Signed-off-by: Roger Pau Monné <[email protected]> Reviewed-by: Juergen Gross <[email protected]> --- drivers/xen/biomerge.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c index 4da69dbf7dca..1bdd02a6d6ac 100644 --- a/drivers/xen/biomerge.c +++ b/drivers/xen/biomerge.c @@ -10,8 +10,7 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1, unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page)); unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page)); - return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) && - ((bfn1 == bfn2) || ((bfn1+1) == bfn2)); + return bfn1 + PFN_DOWN(vec1->bv_offset + vec1->bv_len) == bfn2; #else /* * XXX: Add support for merging bio_vec when using different page -- 2.11.0 (Apple Git-81)