Bugzilla – Bug 1043330
VUL-0: CVE-2017-10911: kernel: xen: blkif responses leak backend stack data (XSA-216)
Last modified: 2020-05-12 18:05:00 UTC
+++ This bug was initially created as a clone of Bug #1042863 +++ Also needs to be dealt with on the kernel side Xen Security Advisory XSA-216 blkif responses leak backend stack data *** EMBARGOED UNTIL 2017-06-20 12:00 UTC *** ISSUE DESCRIPTION ================= The block interface response structure has some discontiguous fields. Certain backends populate the structure fields of an otherwise uninitialized instance of this structure on their stacks, leaking data through the (internal or trailing) padding field. IMPACT ====== A malicious unprivileged guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS ================== All Linux versions supporting the xen-blkback, blkback, or blktap drivers are vulnerable. FreeBSD, NetBSD and Windows (with our without PV drivers) are not vulnerable (either because they do not have backends at all, or because they use a different implementation technique which does not suffer from this problem). All qemu versions supporting the Xen block backend are vulnerable. The qemu-xen-traditional code base does not include such code, so is not vulnerable. Note that an instance of qemu will be spawned to provide the backend for most non-raw-format disks; so you may need to apply the patch to qemu even if you use only PV guests. MITIGATION ========== There's no mitigation available for x86 PV and ARM guests. For x86 HVM guests it may be possible to change the guest configuaration such that a fully virtualized disk is being made available instead. However, this would normally entail changes inside the guest itself. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa216-linux-4.11.patch Linux 4.5 ... 4.11 xsa216-qemuu.patch qemu-upstream master, 4.8 xsa216-qemuu-4.7.patch qemu-upstream 4.7, 4.6 xsa216-qemuu-4.5.patch qemu-upstream 4.5 xsa216-linux-2.6.18-xen.patch linux-2.6.18-xen.hg $ sha256sum xsa216* 28beb3d876fa0eee77f4377ef2708d764a5d9a2003dd4f1a4ecb9b8bf60658a4 xsa216-linux-2.6.18-xen.patch e04da27961cd867f7bbba31677f61e3e425c0e7cc7352a7a2d22b5a35eaf8585 xsa216-linux-4.11.patch 850b0143cfe3c69c62abdad71be9813014d46c380109fc650689a10c90ff39f4 xsa216-qemuu.patch 072270274d2554b71579a529c908d16479f8eba6646d8aed2e3d129495b27716 xsa216-qemuu-4.5.patch 5a64e2c5bb78f1c8fae97354be10fcc63ea39d333d6490e3a422ff30460cdef1 xsa216-qemuu-4.7.patch
is public
The kernel fix was already merged, but with the reference to the original bug 1042863. At least for SLE12-SP2/SP3.
As Takashi already stated: fix is in SLE12 SP2/3
Jan, I think the patch is missing in the xen kernel.
Which branch(es) are you talking about? SLE11 SP4 and SLE12 SP1 both have patches.xen/xsa216.patch, and even some of the LTSS/TD branches have obtained it already afaik.
(In reply to Jan Beulich from comment #8) > Which branch(es) are you talking about? SLE11 SP4 and SLE12 SP1 both have > patches.xen/xsa216.patch, and even some of the LTSS/TD branches have > obtained it already afaik. Sorry, must have either overlooked it or looked at the wrong branch. Sorry for the noise.
Handing on then - Ales, I hope you're the right person for the LTSS branches.
SLE11-SP3-LTSS: the patch is there, I did the merge initially wrong, but since there are no "indirect blkif requests" (whatever that is), I think that the fix should look like what Jan pushed to cve/linux-3.0. SLE12-SP1-LTSS: has the patch SLE12-LTSS: does not (perhaps it better should've went through cve/linux-3.12). As it applies & compiles, I assume it's safe to just take it.
This has been merged -> closing.