dev/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224

Browse Source 
XSA-216 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.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled.  If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted.  Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice.  The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write.  This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables.  At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits.  However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests).  This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear.  However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

> When polling event channels, in general arbitrary port numbers can be
> specified.  Specifically, there is no requirement that a polled event
> channel ports has ever been created.  When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL.  However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping.  When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones).  If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse.  This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts.  When the grant is then unmapped, the
> type count will be erroneously reduced.  This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html
This commit is contained in:
Michał Pałka 2017-06-26 07:00:00 +00:00
parent 4c0203b094
commit 80e0cda7ff
3 changed files with 81 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
pkgs/applications/virtualization/xen/4.5.nix
View File

@ -71,6 +71,10 @@ callPackage (import ./generic.nix (rec {
name = "211-qemuu-4.6";
sha256 = "1g090xs8ca8676vyi78b99z5yjdliw6mxkr521b8kimhf8crx4yg";
})
(xsaPatch {
name = "216-qemuu-4.5";
sha256 = "0nh5akbal93czia1gh1pzvwq7gc4zwiyr1hbyk1m6wwdmqv6ph61";
})
];
meta.description = "Xen's fork of upstream Qemu";
};
@ -342,6 +346,62 @@ callPackage (import ./generic.nix (rec {
name = "215";
sha256 = "0sv8ccc5xp09f1w1gj5a9n3mlsdsh96sdb1n560vh31f4kkd61xs";
})
(xsaPatch {
name = "217-4.5";
sha256 = "067pgsfrb9py2dhm1pk9g8f6fs40vyfrcxhj8c12vzamb6svzmn4";
})
(xsaPatch {
name = "218-4.5/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures";
sha256 = "00y6j3yjxw0igpldsavikmhlxw711k2jsj1qx0s05w2k608gadkq";
})
(xsaPatch {
name = "218-4.5/0002-gnttab-fix-unmap-pin-accounting-race";
sha256 = "0qbbfnnjlpdcd29mzmacfmi859k92c213l91q7w1rg2k6pzx928k";
})
(xsaPatch {
name = "218-4.5/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry";
sha256 = "1cndzvyhf41mk4my6vh3bk9jvh2y4gpmqdhvl9zhxhmppszslqkc";
})
(xsaPatch {
name = "218-4.5/0004-gnttab-correct-maptrack-table-accesses";
sha256 = "02zpb0ffigijacqvyyjylwx3qpgibwslrka7mbxwnclf4s9c03a2";
})
(xsaPatch {
name = "219-4.5";
sha256 = "003msr5vhsc66scmdpgn0lp3p01g4zfw5vj86y5lw9ajkbaywdsm";
})
(xsaPatch {
name = "220-4.5";
sha256 = "1dj9nn6lzxlipjb3nb7b9m4337fl6yn2bd7ap1lqrjn8h9zkk1pp";
})
(xsaPatch {
name = "221";
sha256 = "1mcr1nqgxyjrkywdg7qhlfwgz7vj2if1dhic425vgd41p9cdgl26";
})
(xsaPatch {
name = "222-1-4.6";
sha256 = "1g4dqm5qx4wqlv1520jpfiscph95vllcp4gqp1rdfailk8xi0mcf";
})
(xsaPatch {
name = "222-2-4.5";
sha256 = "1hw8rhc7q4v309f4w11gxfsn5x1pirvxkg7s4kr711fnmvp9hkzd";
})
(xsaPatch {
name = "224-4.5/0001-gnttab-Fix-handling-of-dev_bus_addr-during-unmap";
sha256 = "1aislj66ss4cb3v2bh12mrqsyrf288d4h54rj94jjq7h1hnycw7h";
})
(xsaPatch {
name = "224-4.5/0002-gnttab-never-create-host-mapping-unless-asked-to";
sha256 = "1j6fgm1ccb07gg0mi5qmdr0vqwwc3n12z433g1jrija2gbk1x8aq";
})
(xsaPatch {
name = "224-4.5/0003-gnttab-correct-logic-to-get-page-references-during-m";
sha256 = "166kmicwx280fjqjvgigbmhabjksa0hhvqx5h4v6kjlcjpmxqy08";
})
(xsaPatch {
name = "224-4.5/0004-gnttab-__gnttab_unmap_common_complete-is-all-or-noth";
sha256 = "1skc0yj1zsn8xgyq1y57bdc0scvvlmd0ynrjwwf1zkias1wlilav";
})
];
# Fix build on Glibc 2.24.

17
pkgs/os-specific/linux/kernel/patches.nix
View File

@ -156,4 +156,21 @@ rec {
sha256 = "10dmv3d3gj8rvj9h40js4jh8xbr5wyaqiy0kd819mya441mj8ll2";
};
};
# https://xenbits.xen.org/xsa/advisory-216.html
xen_XSA_216 =
{ name = "xen_XSA-216";
patch = fetchpatch {
url = "https://xenbits.xen.org/xsa/xsa216-linux-4.11.patch";
sha256 = "14h017n6qwnraw5bv72q9xkg2w7xvx290505kny5zfwx891xahs8";
};
};
xen_XSA_216_4-4 =
{ name = "xen_XSA-216-4.4";
patch = fetchpatch {
url = "https://xenbits.xen.org/xsa/xsa216-linux-4.4.patch";
sha256 = "1lv50wpr4lr49i4vp04vl778wcs9xn1jm51hp91h87jr0g3pbvi2";
};
};
}

4
pkgs/top-level/all-packages.nix
View File

@ -11905,6 +11905,7 @@ with pkgs;
[ kernelPatches.bridge_stp_helper
kernelPatches.p9_fixes
kernelPatches.cpu-cgroup-v2."4.4"
kernelPatches.xen_XSA_216_4-4
]
++ lib.optionals ((platform.kernelArch or null) == "mips")
[ kernelPatches.mips_fpureg_emu
@ -11919,6 +11920,7 @@ with pkgs;
kernelPatches.p9_fixes
kernelPatches.cpu-cgroup-v2."4.9"
kernelPatches.modinst_arg_list_too_long
kernelPatches.xen_XSA_216
]
++ lib.optionals ((platform.kernelArch or null) == "mips")
[ kernelPatches.mips_fpureg_emu
@ -11935,6 +11937,7 @@ with pkgs;
# when adding a new linux version
kernelPatches.cpu-cgroup-v2."4.11"
kernelPatches.modinst_arg_list_too_long
kernelPatches.xen_XSA_216
]
++ lib.optionals ((platform.kernelArch or null) == "mips")
[ kernelPatches.mips_fpureg_emu
@ -11948,6 +11951,7 @@ with pkgs;
kernelPatches.bridge_stp_helper
kernelPatches.p9_fixes
kernelPatches.modinst_arg_list_too_long
kernelPatches.xen_XSA_216
] ++ lib.optionals ((platform.kernelArch or null) == "mips") [
kernelPatches.mips_fpureg_emu
kernelPatches.mips_fpu_sigill