From 80e0cda7ff92233edc94161eae5838a1c423e5e4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Pa=C5=82ka?= Date: Mon, 26 Jun 2017 07:00:00 +0000 Subject: [PATCH] xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224 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 --- pkgs/applications/virtualization/xen/4.5.nix | 60 ++++++++++++++++++++ pkgs/os-specific/linux/kernel/patches.nix | 17 ++++++ pkgs/top-level/all-packages.nix | 4 ++ 3 files changed, 81 insertions(+) diff --git a/pkgs/applications/virtualization/xen/4.5.nix b/pkgs/applications/virtualization/xen/4.5.nix index c6aa15221604..5fe4fa823fea 100644 --- a/pkgs/applications/virtualization/xen/4.5.nix +++ b/pkgs/applications/virtualization/xen/4.5.nix @@ -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. diff --git a/pkgs/os-specific/linux/kernel/patches.nix b/pkgs/os-specific/linux/kernel/patches.nix index 1747d34fe112..cbba50710b51 100644 --- a/pkgs/os-specific/linux/kernel/patches.nix +++ b/pkgs/os-specific/linux/kernel/patches.nix @@ -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"; + }; + }; } diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix index 5bb3750340da..4d635a38575b 100644 --- a/pkgs/top-level/all-packages.nix +++ b/pkgs/top-level/all-packages.nix @@ -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