grsec: Apply grsecurity-3.0-3.14.22-201410250026.patch

commit a8ee169c76b4fab6f6adf4ebd56b4dee23b0b4f5
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Fri Oct 17 22:55:59 2014 +0200

    kvm: fix excessive pages un-pinning in kvm_iommu_map error path.

    The third parameter of kvm_unpin_pages() when called from
    kvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin
    and not the page size.

    This error was facilitated with an inconsistent API: kvm_pin_pages() takes
    a size, but kvn_unpin_pages() takes a number of pages, so fix the problem
    by matching the two.

    This was introduced by commit 350b8bd ("kvm: iommu: fix the third parameter
    of kvm_iommu_put_pages (CVE-2014-3601)"), which fixes the lack of
    un-pinning for pages intended to be un-pinned (i.e. memory leak) but
    unfortunately potentially aggravated the number of pages we un-pin that
    should have stayed pinned. As far as I understand though, the same
    practical mitigations apply.

    This issue was found during review of Red Hat 6.6 patches to prepare
    Ksplice rebootless updates.

    Thanks to Vegard for his time on a late Friday evening to help me in
    understanding this code.

    Fixes: 350b8bd ("kvm: iommu: fix the third parameter of... (CVE-2014-3601)")
    Cc: stable@vger.kernel.org
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
    Reviewed-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 virt/kvm/iommu.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

commit 0eee7e7448e396c762d91984b588d017becbb09d
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Oct 23 12:58:13 2014 -0700

    sparc64: Fix register corruption in top-most kernel stack frame during boot.

    Meelis Roos reported that kernels built with gcc-4.9 do not boot, we
    eventually narrowed this down to only impacting machines using
    UltraSPARC-III and derivitive cpus.

    The crash happens right when the first user process is spawned:

    [   54.451346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
    [   54.451346]
    [   54.571516] CPU: 1 PID: 1 Comm: init Not tainted 3.16.0-rc2-00211-gd7933ab #96
    [   54.666431] Call Trace:
    [   54.698453]  [0000000000762f8c] panic+0xb0/0x224
    [   54.759071]  [000000000045cf68] do_exit+0x948/0x960
    [   54.823123]  [000000000042cbc0] fault_in_user_windows+0xe0/0x100
    [   54.902036]  [0000000000404ad0] __handle_user_windows+0x0/0x10
    [   54.978662] Press Stop-A (L1-A) to return to the boot prom
    [   55.050713] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

    Further investigation showed that compiling only per_cpu_patch() with
    an older compiler fixes the boot.

    Detailed analysis showed that the function is not being miscompiled by
    gcc-4.9, but it is using a different register allocation ordering.

    With the gcc-4.9 compiled function, something during the code patching
    causes some of the %i* input registers to get corrupted.  Perhaps
    we have a TLB miss path into the firmware that is deep enough to
    cause a register window spill and subsequent restore when we get
    back from the TLB miss trap.

    Let's plug this up by doing two things:

    1) Stop using the firmware stack for client interface calls into
       the firmware.  Just use the kernel's stack.

    2) As soon as we can, call into a new function "start_early_boot()"
       to put a one-register-window buffer between the firmware's
       deepest stack frame and the top-most initial kernel one.

    Reported-by: Meelis Roos <mroos@linux.ee>
    Tested-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: David S. Miller <davem@davemloft.net>

    Conflicts:

    	arch/sparc/include/asm/oplib_64.h
    	arch/sparc/include/asm/setup.h
    	arch/sparc/kernel/entry.h

 arch/sparc/include/asm/oplib_64.h |    3 +-
 arch/sparc/include/asm/setup.h    |    4 +++
 arch/sparc/kernel/entry.h         |   11 +++------
 arch/sparc/kernel/head_64.S       |   40 +++---------------------------------
 arch/sparc/kernel/hvtramp.S       |    1 -
 arch/sparc/kernel/setup_64.c      |   28 ++++++++++++++++++-------
 arch/sparc/kernel/trampoline_64.S |   12 ++++++----
 arch/sparc/prom/cif.S             |    5 +--
 arch/sparc/prom/init_64.c         |    6 ++--
 arch/sparc/prom/p1275.c           |    2 -
 10 files changed, 46 insertions(+), 66 deletions(-)

commit e097432d404243fff21a5fc7e1b0fae16ac8d494
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Oct 24 09:59:02 2014 -0700

    sparc64: Implement __get_user_pages_fast().

    It is not sufficient to only implement get_user_pages_fast(), you
    must also implement the atomic version __get_user_pages_fast()
    otherwise you end up using the weak symbol fallback implementation
    which simply returns zero.

    This is dangerous, because it causes the futex code to loop forever
    if transparent hugepages are supported (see get_futex_key()).

    Signed-off-by: David S. Miller <davem@davemloft.net>

 arch/sparc/mm/gup.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

commit 7b1ebc6b0c9ab5ffe46742ab8b5eecfe8f1d7945
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 18:01:34 2014 -0600

    x86, intel-mid: Remove "weak" from function declarations

    For the following interfaces:

      get_penwell_ops()
      get_cloverview_ops()
      get_tangier_ops()

    there is only one implementation, so they do not need to be marked "weak".

    Remove the "weak" attribute from their declarations.

    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    CC: David Cohen <david.a.cohen@linux.intel.com>
    CC: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    CC: x86@kernel.org
    Conflicts:

    	arch/x86/platform/intel-mid/intel_mid_weak_decls.h

    Conflicts:

    	arch/x86/platform/intel-mid/intel_mid_weak_decls.h

 arch/x86/platform/intel-mid/intel_mid_weak_decls.h |    7 +++----
 arch/x86/platform/intel-mid/mfld.c                 |    4 ++--
 arch/x86/platform/intel-mid/mrfl.c                 |    2 +-
 3 files changed, 6 insertions(+), 7 deletions(-)

commit 6c7d2283a0b891e3798d628ba23869e87d2df378
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 18:59:09 2014 -0600

    clocksource: Remove "weak" from clocksource_default_clock() declaration

    kernel/time/jiffies.c provides a default clocksource_default_clock()
    definition explicitly marked "weak".  arch/s390 provides its own definition
    intended to override the default, but the "weak" attribute on the
    declaration applied to the s390 definition as well, so the linker chose one
    based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from
    pcibios_get_phb_of_node decl")).

    Remove the "weak" attribute from the clocksource_default_clock()
    declaration so we always prefer a non-weak definition over the weak one,
    independent of link order.

    Fixes: f1b82746c1e9 ("clocksource: Cleanup clocksource selection")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: John Stultz <john.stultz@linaro.org>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    CC: Daniel Lezcano <daniel.lezcano@linaro.org>
    CC: Martin Schwidefsky <schwidefsky@de.ibm.com>

 include/linux/clocksource.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 94d5fc2f833615221953713c50482de19add9cd6
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 18:59:41 2014 -0600

    vmcore: Remove "weak" from function declarations

    For the following functions:

      elfcorehdr_alloc()
      elfcorehdr_free()
      elfcorehdr_read()
      elfcorehdr_read_notes()
      remap_oldmem_pfn_range()

    fs/proc/vmcore.c provides default definitions explicitly marked "weak".
    arch/s390 provides its own definitions intended to override the default
    ones, but the "weak" attribute on the declarations applied to the s390
    definitions as well, so the linker chose one based on link order (see
    10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node
    decl")).

    Remove the "weak" attribute from the declarations so we always prefer a
    non-weak definition over the weak one, independent of link order.

    Fixes: be8a8d069e50 ("vmcore: introduce ELF header in new memory feature")
    Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    CC: Michael Holzheu <holzheu@linux.vnet.ibm.com>

 include/linux/crash_dump.h |   15 +++++++--------
 1 files changed, 7 insertions(+), 8 deletions(-)

commit a69ac3a59aee2e75db96470f1c9053e0952998b6
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Mon Oct 20 10:17:04 2014 -0600

    ARC: kgdb: generic kgdb_arch_pc() suffices

    The ARC version of kgdb_arch_pc() is identical to the generic version in
    kernel/debug/debug_core.c.  Drop the ARC version so we use the generic one.

    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

 arch/arc/kernel/kgdb.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

commit 21560a63031fe5d22c71cae090cf92fdfc6dc273
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 19:00:25 2014 -0600

    kgdb: Remove "weak" from kgdb_arch_pc() declaration

    kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition
    explicitly marked "weak".  Several architectures provide their own
    definitions intended to override the default, but the "weak" attribute on
    the declaration applied to the arch definitions as well, so the linker
    chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
    annotation from pcibios_get_phb_of_node decl")).

    Remove the "weak" attribute from the declaration so we always prefer a
    non-weak definition over the weak one, independent of link order.

    Fixes: 688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add declaration to header")
    Tested-by: Vineet Gupta <vgupta@synopsys.com>	# for ARC build
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Harvey Harrison <harvey.harrison@gmail.com>

 include/linux/kgdb.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit ddc947af9fabf397a2cf742123f64bf78028e9dc
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 19:00:47 2014 -0600

    memory-hotplug: Remove "weak" from memory_block_size_bytes() declaration

    drivers/base/memory.c provides a default memory_block_size_bytes()
    definition explicitly marked "weak".  Several architectures provide their
    own definitions intended to override the default, but the "weak" attribute
    on the declaration applied to the arch definitions as well, so the linker
    chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
    annotation from pcibios_get_phb_of_node decl")).

    Remove the "weak" attribute from the declaration so we always prefer a
    non-weak definition over the weak one, independent of link order.

    Fixes: 41f107266b19 ("drivers: base: Add prototype declaration to the header file")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    CC: Rashika Kheria <rashika.kheria@gmail.com>
    CC: Nathan Fontenot <nfont@austin.ibm.com>
    CC: Anton Blanchard <anton@au1.ibm.com>
    CC: Heiko Carstens <heiko.carstens@de.ibm.com>
    CC: Yinghai Lu <yinghai@kernel.org>

 include/linux/memory.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit d2c7990f8f104ba878e2000efa2be6df3e74ceed
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sun Sep 7 23:23:38 2014 +0200

    crypto: memzero_explicit - make sure to clear out sensitive data

    Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
    for clearing data"), we have found that GCC may optimize some memset()
    cases away when it detects a stack variable is not being used anymore
    and going out of scope. This can happen, for example, in cases when we
    are clearing out sensitive information such as keying material or any
    e.g. intermediate results from crypto computations, etc.

    With the help of Coccinelle, we can figure out and fix such occurences
    in the crypto subsytem as well. Julia Lawall provided the following
    Coccinelle program:

      @@
      type T;
      identifier x;
      @@

      T x;
      ... when exists
          when any
      -memset
      +memzero_explicit
         (&x,
      -0,
         ...)
      ... when != x
          when strict

      @@
      type T;
      identifier x;
      @@

      T x[...];
      ... when exists
          when any
      -memset
      +memzero_explicit
         (x,
      -0,
         ...)
      ... when != x
          when strict

    Therefore, make use of the drop-in replacement memzero_explicit() for
    exactly such cases instead of using memset().

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Julia Lawall <julia.lawall@lip6.fr>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>

 crypto/cts.c            |    3 ++-
 crypto/sha1_generic.c   |    2 +-
 crypto/sha256_generic.c |    5 ++---
 crypto/sha512_generic.c |    2 +-
 crypto/tgr192.c         |    4 ++--
 crypto/vmac.c           |    2 +-
 crypto/wp512.c          |    8 ++++----
 7 files changed, 13 insertions(+), 13 deletions(-)

commit 9834d21f9fb72e5eabbfc5290261987ae21133af
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Tue Aug 26 23:16:35 2014 -0400

    random: add and use memzero_explicit() for clearing data

    zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
    memset() calls which clear out sensitive data in extract_{buf,entropy,
    entropy_user}() in random driver are being optimized away by gcc.

    Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
    that can be used in such cases where a variable with sensitive data is
    being cleared out in the end. Other use cases might also be in crypto
    code. [ I have put this into lib/string.c though, as it's always built-in
    and doesn't need any dependencies then. ]

    Fixes kernel bugzilla: 82041

    Reported-by: zatimend@hotmail.co.uk
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org

    Conflicts:

    	drivers/char/random.c

 drivers/char/random.c  |   10 +++++-----
 include/linux/string.h |    5 +++--
 lib/string.c           |   16 ++++++++++++++++
 3 files changed, 24 insertions(+), 7 deletions(-)

commit 26b683871a4b2dafca09f16efd38101a5d97abba
Author: Li RongQing <roy.qing.li@gmail.com>
Date:   Wed Oct 22 17:09:53 2014 +0800

    xfrm6: fix a potential use after free in xfrm6_policy.c

    pskb_may_pull() maybe change skb->data and make nh and exthdr pointer
    oboslete, so recompute the nd and exthdr

    Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

 net/ipv6/xfrm6_policy.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

commit 9f9123ab40959f0c63f267a46016c6d0fa823c2f
Author: Brad Spengler <spender@grsecurity.net>
Date:   Thu Oct 23 19:20:18 2014 -0400

    allow print_bad_pte to display symbols

 mm/memory.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

commit a6f917db2aff6f1156220d766c3de2933261c2c1
Author: Brad Spengler <spender@grsecurity.net>
Date:   Wed Oct 22 18:36:16 2014 -0400

    Remove argument from gr_update_task_in_ip_table, as it's always called with 'current'

    Conflicts:

    	net/ipv4/inet_hashtables.c

 grsecurity/grsec_sock.c    |    4 ++--
 net/ipv4/inet_hashtables.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

commit 481cc2a6877c249b8d32ae06575cb5ee05290d77
Author: Brad Spengler <spender@grsecurity.net>
Date:   Wed Oct 22 18:19:01 2014 -0400

    hold sighand lock while accessing ->signal

 fs/proc/array.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

Signature-tree: eaf464144c201563e134ebf9eca041aa31848928