Commit Graph

360 Commits

Author SHA1 Message Date
Florian Klink
f919c7faec linux_4_14: fix iwlwifi fw reset
Currently, moving to kernel_4_14 breaks at least Intel Wireless 8260 and
8265 cards due to a API change in the firmware, which is not yet honored
in the driver.
2017-11-15 11:30:24 +00:00
Matthieu Coudron
7dce131b86 kernelmptcp: 0.91.3 -> 0.92.1 2017-11-02 13:14:57 +01:00
Jörg Thalheim
44f93731d6 linux_chromiumos_3_18: remove kernel due lack of maintainer/breakage
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.

For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
2017-09-05 14:42:23 +02:00
Joachim Fasting
697cbbc617
kernelPatches.grsecurity_testing: remove 2017-09-02 15:56:49 +02:00
Robin Gloster
05b8cae9ec
linux: remove unused kernel patches 2017-08-11 19:13:09 +02:00
Tim Steinbach
ff10bafd00
linux: Expand hardened config
Based on latest recommendations at
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
2017-08-06 09:58:02 -04:00
Tim Steinbach
d1aff8d2e5
linux: 4.9.34 -> 4.9.35
Also, remove XSA-216 patches, the fixes are now integrated upstream
2017-06-29 08:26:25 -04:00
Michał Pałka
80e0cda7ff 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
2017-06-26 07:01:24 +00:00
Joachim Fasting
ab4fa1cce4
tree-wide: prune some dead grsec leaves
The beginning of pruning grsecurity/PaX from the tree.
2017-04-30 12:05:41 +02:00
Joachim Fasting
32b8512e54
grsecurity: discontinue support
Upstream has decided to make -testing patches private, effectively ceasing
free support for grsecurity/PaX [1].  Consequently, we can no longer
responsibly support grsecurity on NixOS.

This patch turns the kernel and patch expressions into build errors and
adds a warning to the manual, but retains most of the infrastructure, in
an effort to make the transition smoother.  For 17.09 all of it should
probably be pruned.

[1]: https://grsecurity.net/passing_the_baton.php
2017-04-28 12:35:15 +02:00
Jason A. Donenfeld
b1750d699c linux-chromiumos: remove 3.14
3.14 is no longer supported upstream by kernel.org and thus no longer
receives security patches. The git commit mentioned in this .nix isn't
even available in the linked repository --
https://chromium.googlesource.com/chromiumos/third_party/kernel -- so I
think this .nix might be dead anyway. Finally, it specifies 3.14.0,
which is so ridiculously old (the latest was 3.14.79) that nobody
develops for it.

Fixes: #25145
Supports: #25127
2017-04-23 15:47:46 +02:00
Joachim Fasting
9e6c96f8fc
grsecurity: 4.9.24-201704210851 -> 4.9.24-2201704220732 2017-04-22 16:37:24 +02:00
Joachim Fasting
05911da7bb
grsecurity: 4.9.23-201704181901 -> 4.9.24-201704210851 2017-04-21 15:09:32 +02:00
Joachim Fasting
9902d63e84
grsecurity: 4.9.22-201704120836 -> 4.9.23-201704181901 2017-04-20 00:21:41 +02:00
Joachim Fasting
3fa5605b41
grsecurity: 4.9.21-201704091948 -> 4.9.22-201704120836 2017-04-12 18:58:29 +02:00
Joachim Fasting
7701cbca6b
grsecurity: 4.9.20-201703310823 -> 4.9.21-201704091948 2017-04-10 03:34:42 +02:00
Volth
ed41d50e9f kernel: fix 9p issues
[tuomas: rename the patch from 9p-hacks to something slighly more
meaningful]
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
2017-04-01 15:49:14 +03:00
Joachim Fasting
a41668f441
grsecurity: 4.9.19-201703300917 -> 4.9.20-201703310823 2017-04-01 00:08:50 +02:00
Joachim Fasting
4d4488e793
grsecurity: 4.9.18-201703261106 -> 4.9.19-201703300917 2017-03-30 16:28:34 +02:00
Joachim Fasting
5fe81c1bdb
grsecurity: 4.9.17-201703221829 -> 4.9.18-201703261106 2017-03-26 21:35:36 +02:00
Joachim Fasting
94ab4932ae
grsecurity: 4.9.16-201703180820 -> 4.9.17-201703221829 2017-03-23 01:03:14 +01:00
Joachim Fasting
d4409817a6
grsecurity: 4.9.15-201703150049 -> 4.9.16-201703180820 2017-03-18 15:32:48 +01:00
Joachim Fasting
9e60a17cb8
grsecurity: 4.9.14-201703121245 -> 4.9.15-201703150049
Contains a fix for the n_hdlc double free bug.
2017-03-15 07:25:21 +01:00
Joachim Fasting
4c211bdc63
grsecurity: 4.9.13-201703052141 -> 4.9.14-201703121245 2017-03-12 18:44:27 +01:00
Joachim Fasting
17d80c49fa
grsecurity: 4.9.13-201702270729 -> 201703052141 2017-03-06 15:59:30 +01:00
Joachim Fasting
a20a53300d
grsecurity: 4.9.13-201702261126 -> 201702270729 2017-02-27 16:04:32 +01:00
Joachim Fasting
f3a6991f3d
grsecurity: 4.9.12-201702231830 -> 4.9.13-201702261126 2017-02-26 18:20:50 +01:00
Joachim Fasting
0150d9a95c
grsecurity: 4.9.11-201702222257 -> 4.9.12-201702231830 2017-02-26 14:01:57 +01:00
Graham Christensen
d36b1ccc13
Revert "Revert "linux kernels: patch against DCCP double free (CVE-2017-6074)""
This reverts commit 53a2baabbe.
2017-02-23 19:23:29 -05:00
Graham Christensen
53a2baabbe
Revert "linux kernels: patch against DCCP double free (CVE-2017-6074)"
This reverts commit 1d68edbef4.
2017-02-23 18:47:16 -05:00
Graham Christensen
1d68edbef4
linux kernels: patch against DCCP double free (CVE-2017-6074) 2017-02-23 18:44:43 -05:00
Joachim Fasting
b92501f0d8
grsecurity: 4.9.11-201702181444 -> 201702222257 2017-02-23 19:18:39 +01:00
Tim Steinbach
2423313581
kernel: 4.9.10 -> 4.9.11 2017-02-18 18:33:36 -05:00
Joachim Fasting
ca016c2626
grsecurity: 4.9.10-201702152052 -> 4.9.11-201702181444 2017-02-18 22:01:16 +01:00
Joachim Fasting
e8007c0e89
linux_4_9: patch for CVE-2017-5986
Seems fairly low impact[1] but we might as well patch it until a new 4.9
version is released

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1420276
2017-02-17 19:11:30 +01:00
Joachim Fasting
bc2f53fd29
grsecurity: 4.9.8-201702071801 -> 4.9.10-201702152052 2017-02-16 14:51:25 +01:00
Eelco Dolstra
c71a893334
Revert "Use looser 9pfs caching in VM tests/builds"
This reverts commit bbd03e236a.
2017-02-13 14:38:19 +01:00
Eelco Dolstra
4af79a7331
Revert "linux: Apply 9p veryloose patch to 4.9"
This reverts commit a82810c7a7.

Fixes #22695.
2017-02-13 12:16:39 +01:00
Joachim Fasting
bd46a375df
grsecurity: 4.9.8-201702060653 -> 201702071801 2017-02-08 01:31:18 +01:00
Joachim Fasting
0d422c5db5
grsecurity: 4.8.17-201701151620 -> 4.9.8-201702060653
The first release in the 4.9 branch.

I've also migrated my update scripts to SHA-512 so that'll
be the hash of choice for grsec packages going forward.
2017-02-06 15:49:34 +01:00
Joachim Fasting
c50c551142
grsecurity: 4.8.16-201701062021 -> 4.8.17-201701151620 2017-01-25 00:58:57 +01:00
Joachim Fasting
482c67af70
grsecurity: adapt new to mirror url structure 2017-01-25 00:58:54 +01:00
Eelco Dolstra
a82810c7a7
linux: Apply 9p veryloose patch to 4.9 2017-01-24 13:05:02 +01:00
Joachim Fasting
d6ff445f10
grsecurity: 4.8.15-201612301949 -> 4.8.16-201701062021 2017-01-07 08:01:41 +01:00
Joachim Fasting
75ce714818
grsecurity: 4.8.15-201612151923 -> 201612301949 2017-01-01 06:01:04 +01:00
Eelco Dolstra
bbd03e236a
Use looser 9pfs caching in VM tests/builds
This can give significant speed ups, see
7e20254412.
2016-12-29 21:26:16 +01:00
Franz Pletz
c6bcc485de
linux_4_8: add patch to fix CVE-2016-9919 2016-12-28 06:35:11 +01:00
Joachim Fasting
f0e77cd07d
grsecurity: 4.8.14-201612110933 -> 4.8.15-201612151923 2016-12-16 12:46:44 +01:00
Graham Christensen
01d022e16b Merge pull request #21118 from grahamc/fix-rsa-build-failure
linux_{4_8,grsec_nixos}: patch to fix build failure
2016-12-13 09:15:50 -05:00
Graham Christensen
7a813d3f6d
linux_{4_8,grsec_nixos}: patch to fix build failure
crypto/rsa_helper.c:18:28: fatal error: rsapubkey-asn1.h: No such file or directory
2016-12-13 07:25:46 -05:00