forked from mirrors/nixpkgs
80e0cda7ff
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
177 lines
5 KiB
Nix
177 lines
5 KiB
Nix
{ stdenv, fetchurl, fetchpatch, pkgs }:
|
|
|
|
let
|
|
|
|
makeTuxonicePatch = { version, kernelVersion, sha256,
|
|
url ? "http://tuxonice.nigelcunningham.com.au/downloads/all/tuxonice-for-linux-${kernelVersion}-${version}.patch.bz2" }:
|
|
{ name = "tuxonice-${kernelVersion}";
|
|
patch = stdenv.mkDerivation {
|
|
name = "tuxonice-${version}-for-${kernelVersion}.patch";
|
|
src = fetchurl {
|
|
inherit url sha256;
|
|
};
|
|
phases = [ "installPhase" ];
|
|
installPhase = ''
|
|
source $stdenv/setup
|
|
bunzip2 -c $src > $out
|
|
'';
|
|
};
|
|
};
|
|
in
|
|
|
|
rec {
|
|
|
|
multithreaded_rsapubkey =
|
|
{
|
|
name = "multithreaded-rsapubkey-asn1.patch";
|
|
patch = ./multithreaded-rsapubkey-asn1.patch;
|
|
};
|
|
|
|
bridge_stp_helper =
|
|
{ name = "bridge-stp-helper";
|
|
patch = ./bridge-stp-helper.patch;
|
|
};
|
|
|
|
p9_fixes =
|
|
{ name = "p9-fixes";
|
|
patch = ./p9-fixes.patch;
|
|
};
|
|
|
|
no_xsave =
|
|
{ name = "no-xsave";
|
|
patch = ./no-xsave.patch;
|
|
features.noXsave = true;
|
|
};
|
|
|
|
mips_fpureg_emu =
|
|
{ name = "mips-fpureg-emulation";
|
|
patch = ./mips-fpureg-emulation.patch;
|
|
};
|
|
|
|
mips_fpu_sigill =
|
|
{ name = "mips-fpu-sigill";
|
|
patch = ./mips-fpu-sigill.patch;
|
|
};
|
|
|
|
mips_ext3_n32 =
|
|
{ name = "mips-ext3-n32";
|
|
patch = ./mips-ext3-n32.patch;
|
|
};
|
|
|
|
modinst_arg_list_too_long =
|
|
{ name = "modinst-arglist-too-long";
|
|
patch = ./modinst-arg-list-too-long.patch;
|
|
};
|
|
|
|
ubuntu_fan_4_4 =
|
|
{ name = "ubuntu-fan";
|
|
patch = ./ubuntu-fan-4.4.patch;
|
|
};
|
|
|
|
ubuntu_unprivileged_overlayfs =
|
|
{ name = "ubuntu-unprivileged-overlayfs";
|
|
patch = ./ubuntu-unprivileged-overlayfs.patch;
|
|
};
|
|
|
|
tuxonice_3_10 = makeTuxonicePatch {
|
|
version = "2013-11-07";
|
|
kernelVersion = "3.10.18";
|
|
sha256 = "00b1rqgd4yr206dxp4mcymr56ymbjcjfa4m82pxw73khj032qw3j";
|
|
};
|
|
|
|
grsecurity_testing = throw ''
|
|
Upstream has ceased free support for grsecurity/PaX.
|
|
|
|
See https://grsecurity.net/passing_the_baton.php
|
|
and https://grsecurity.net/passing_the_baton_faq.php
|
|
for more information.
|
|
'';
|
|
|
|
crc_regression =
|
|
{ name = "crc-backport-regression";
|
|
patch = ./crc-regression.patch;
|
|
};
|
|
|
|
genksyms_fix_segfault =
|
|
{ name = "genksyms-fix-segfault";
|
|
patch = ./genksyms-fix-segfault.patch;
|
|
};
|
|
|
|
chromiumos_Kconfig_fix_entries_3_18 =
|
|
{ name = "Kconfig_fix_entries_3_18";
|
|
patch = ./chromiumos-patches/fix-double-Kconfig-entry-3.18.patch;
|
|
};
|
|
|
|
chromiumos_no_link_restrictions =
|
|
{ name = "chromium-no-link-restrictions";
|
|
patch = ./chromiumos-patches/no-link-restrictions.patch;
|
|
};
|
|
|
|
chromiumos_mfd_fix_dependency =
|
|
{ name = "mfd_fix_dependency";
|
|
patch = ./chromiumos-patches/mfd-fix-dependency.patch;
|
|
};
|
|
|
|
hiddev_CVE_2016_5829 =
|
|
{ name = "hiddev_CVE_2016_5829";
|
|
patch = fetchpatch {
|
|
url = "https://sources.debian.net/data/main/l/linux/4.6.3-1/debian/patches/bugfix/all/HID-hiddev-validate-num_values-for-HIDIOCGUSAGES-HID.patch";
|
|
sha256 = "14rm1qr87p7a5prz8g5fwbpxzdp3ighj095x8rvhm8csm20wspyy";
|
|
};
|
|
};
|
|
|
|
cpu-cgroup-v2 = import ./cpu-cgroup-v2-patches;
|
|
|
|
lguest_entry-linkage =
|
|
{ name = "lguest-asmlinkage.patch";
|
|
patch = fetchpatch {
|
|
url = "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git"
|
|
+ "/patch/drivers/lguest/x86/core.c?id=cdd77e87eae52";
|
|
sha256 = "04xlx6al10cw039av6jkby7gx64zayj8m1k9iza40sw0fydcfqhc";
|
|
};
|
|
};
|
|
|
|
packet_fix_race_condition_CVE_2016_8655 =
|
|
{ name = "packet_fix_race_condition_CVE_2016_8655.patch";
|
|
patch = fetchpatch {
|
|
url = "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=84ac7260236a49c79eede91617700174c2c19b0c";
|
|
sha256 = "19viqjjgq8j8jiz5yhgmzwhqvhwv175q645qdazd1k69d25nv2ki";
|
|
};
|
|
};
|
|
|
|
panic_on_icmp6_frag_CVE_2016_9919 = rec
|
|
{ name = "panic_on_icmp6_frag_CVE_2016_9919.patch";
|
|
patch = fetchpatch {
|
|
inherit name;
|
|
url = "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2";
|
|
sha256 = "0mps33r4mnwiy0bmgrzgqkrk59yya17v6kzpv9024g4xlz61rk8p";
|
|
};
|
|
};
|
|
|
|
DCCP_double_free_vulnerability_CVE-2017-6074 = rec
|
|
{ name = "DCCP_double_free_vulnerability_CVE-2017-6074.patch";
|
|
patch = fetchpatch {
|
|
inherit name;
|
|
url = "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4";
|
|
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";
|
|
};
|
|
};
|
|
}
|