grsec: Apply grsecurity-3.0-3.17.1-201410250027.patch

commit c1d74661db03224813ae4fe0ceb50854544ff75c
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Mon Oct 13 13:04:14 2014 +0300

    KVM: x86: PREFETCH and HINT_NOP should have SrcMem flag

    The decode phase of the x86 emulator assumes that every instruction with the
    ModRM flag, and which can be used with RIP-relative addressing, has either
    SrcMem or DstMem.  This is not the case for several instructions - prefetch,
    hint-nop and clflush.

    Adding SrcMem|NoAccess for prefetch and hint-nop and SrcMem for clflush.

    This fixes CVE-2014-8480.

    Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

commit 225788f25d44957a8ccdcd4f26b0181eba694e2c
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Mon Oct 13 13:04:13 2014 +0300

    KVM: x86: Emulator does not decode clflush well

    Currently, all group15 instructions are decoded as clflush (e.g., mfence,
    xsave).  In addition, the clflush instruction requires no prefix (66/f2/f3)
    would exist. If prefix exists it may encode a different instruction (e.g.,
    clflushopt).

    Creating a group for clflush, and different group for each prefix.

    This has been the case forever, but the next patch needs the cflush group
    in order to fix a bug introduced in 3.17.

    Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

commit cce8ff8164083a23c507ee339eb5ed956723837f
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Thu Sep 18 22:39:38 2014 +0300

    KVM: x86: Emulator fixes for eip canonical checks on near branches

    Before changing rip (during jmp, call, ret, etc.) the target should be asserted
    to be canonical one, as real CPUs do.  During sysret, both target rsp and rip
    should be canonical. If any of these values is noncanonical, a #GP exception
    should occur.  The exception to this rule are syscall and sysenter instructions
    in which the assigned rip is checked during the assignment to the relevant
    MSRs.

    This patch fixes the emulator to behave as real CPUs do for near branches.
    Far branches are handled by the next patch.

    This fixes CVE-2014-3647.

    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |   78 +++++++++++++++++++++++++++++++++---------------
 1 files changed, 54 insertions(+), 24 deletions(-)

commit 2cd6c77a29a3c28c67f1bddd4e72d741cea6da50
Author: Andy Honig <ahonig@google.com>
Date:   Wed Aug 27 11:16:44 2014 -0700

    KVM: x86: Prevent host from panicking on shared MSR writes.

    The previous patch blocked invalid writes directly when the MSR
    is written.  As a precaution, prevent future similar mistakes by
    gracefulling handle GPs caused by writes to shared MSRs.

    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Honig <ahonig@google.com>
    [Remove parts obsoleted by Nadav's patch. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/include/asm/kvm_host.h |    2 +-
 arch/x86/kvm/vmx.c              |    7 +++++--
 arch/x86/kvm/x86.c              |   11 ++++++++---
 3 files changed, 14 insertions(+), 6 deletions(-)

commit a86abc5d1f3999cc30e4b6ca9a4d06897f972d4f
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Tue Sep 16 03:24:05 2014 +0300

    KVM: x86: Check non-canonical addresses upon WRMSR

    Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is
    written to certain MSRs. The behavior is "almost" identical for AMD and Intel
    (ignoring MSRs that are not implemented in either architecture since they would
    anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if
    non-canonical address is written on Intel but not on AMD (which ignores the top
    32-bits).

    Accordingly, this patch injects a #GP on the MSRs which behave identically on
    Intel and AMD.  To eliminate the differences between the architecutres, the
    value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to
    canonical value before writing instead of injecting a #GP.

    Some references from Intel and AMD manuals:

    According to Intel SDM description of WRMSR instruction #GP is expected on
    WRMSR "If the source register contains a non-canonical address and ECX
    specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE,
    IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP."

    According to AMD manual instruction manual:
    LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the
    LSTAR and CSTAR registers.  If an RIP written by WRMSR is not in canonical
    form, a general-protection exception (#GP) occurs."
    IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the
    base field must be in canonical form or a #GP fault will occur."
    IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must
    be in canonical form."

    This patch fixes CVE-2014-3610.

    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/include/asm/kvm_host.h |   14 ++++++++++++++
 arch/x86/kvm/svm.c              |    2 +-
 arch/x86/kvm/vmx.c              |    2 +-
 arch/x86/kvm/x86.c              |   27 ++++++++++++++++++++++++++-
 4 files changed, 42 insertions(+), 3 deletions(-)

commit e4b285e5033b2db2b7879167cfaaf77ecb207213
Author: Andy Honig <ahonig@google.com>
Date:   Wed Aug 27 14:42:54 2014 -0700

    KVM: x86: Improve thread safety in pit

    There's a race condition in the PIT emulation code in KVM.  In
    __kvm_migrate_pit_timer the pit_timer object is accessed without
    synchronization.  If the race condition occurs at the wrong time this
    can crash the host kernel.

    This fixes CVE-2014-3611.

    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/i8254.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

commit 7fef9c4865e7e1f10eedac13a29e86b3968effd8
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Thu Sep 18 22:39:37 2014 +0300

    KVM: x86: Fix wrong masking on relative jump/call

    Relative jumps and calls do the masking according to the operand size, and not
    according to the address size as the KVM emulator does today.

    This patch fixes KVM behavior.

    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |   27 ++++++++++++++++++++++-----
 1 files changed, 22 insertions(+), 5 deletions(-)

commit 3522a323e3f9379e23628b4023f8eb237fa94f96
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Thu Sep 18 22:39:39 2014 +0300

    KVM: x86: Handle errors when RIP is set during far jumps

    Far jmp/call/ret may fault while loading a new RIP.  Currently KVM does not
    handle this case, and may result in failed vm-entry once the assignment is
    done.  The tricky part of doing so is that loading the new CS affects the
    VMCS/VMCB state, so if we fail during loading the new RIP, we are left in
    unconsistent state.  Therefore, this patch saves on 64-bit the old CS
    descriptor and restores it if loading RIP failed.

    This fixes CVE-2014-3647.

    Cc: stable@vger.kernel.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |  118 +++++++++++++++++++++++++++++++++++------------
 1 files changed, 88 insertions(+), 30 deletions(-)

commit 992d1e8ef00f79b71ebd1757d3564601d3e0cbe1
Author: Petr Matousek <pmatouse@redhat.com>
Date:   Tue Sep 23 20:22:30 2014 +0200

    kvm: vmx: handle invvpid vm exit gracefully

    On systems with invvpid instruction support (corresponding bit in
    IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid
    causes vm exit, which is currently not handled and results in
    propagation of unknown exit to userspace.

    Fix this by installing an invvpid vm exit handler.

    This is CVE-2014-3646.

    Cc: stable@vger.kernel.org
    Signed-off-by: Petr Matousek <pmatouse@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/include/uapi/asm/vmx.h |    2 ++
 arch/x86/kvm/vmx.c              |    9 ++++++++-
 2 files changed, 10 insertions(+), 1 deletions(-)

commit a5d8d5cdec7f5389cd74d1671ce3ba0613a0f19c
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Sep 18 16:21:16 2014 +0300

    kvm: x86: don't kill guest on unknown exit reason

    KVM_EXIT_UNKNOWN is a kvm bug, we don't really know whether it was
    triggered by a priveledged application.  Let's not kill the guest: WARN
    and inject #UD instead.

    Cc: stable@vger.kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/svm.c |    6 +++---
 arch/x86/kvm/vmx.c |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

commit c18125dc3007b407b1c1ee6f63b70fa334cdaa4f
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Fri Oct 3 01:10:04 2014 +0300

    KVM: x86: Decoding guest instructions which cross page boundary may fail

    Once an instruction crosses a page boundary, the size read from the second page
    disregards the common case that part of the operand resides on the first page.
    As a result, fetch of long insturctions may fail, and thereby cause the
    decoding to fail as well.

    Cc: stable@vger.kernel.org
    Fixes: 5cfc7e0f5e5e1adf998df94f8e36edaf5d30d38e
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

commit 52f3e9b00ed4a9a4242ce8da933a21e89b24d6e6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Oct 23 14:54:14 2014 +0200

    KVM: emulate: avoid accessing NULL ctxt->memopp

    A failure to decode the instruction can cause a NULL pointer access.
    This is fixed simply by moving the "done" label as close as possible
    to the return.

    This fixes CVE-2014-8481.

    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Cc: stable@vger.kernel.org
    Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kvm/emulate.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit e2b6116304cd789559f0838da870dd9b5bebd92b
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 a11f76d9ebd8f4c51cad55859c4542b9de506b78
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>

 arch/sparc/include/asm/oplib_64.h |    3 +-
 arch/sparc/include/asm/setup.h    |    2 +
 arch/sparc/kernel/entry.h         |    3 --
 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, 40 insertions(+), 62 deletions(-)

commit 6b2ca0ac2281209d949162cc39d642ccb4949240
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 0577b0536cd8f7906989aae6928053f8b490cae8
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 18:58:48 2014 -0600

    audit: Remove "weak" from audit_classify_compat_syscall() declaration

    There's only one audit_classify_compat_syscall() definition, so it doesn't
    need to be weak.

    Remove the "weak" attribute from the audit_classify_compat_syscall()
    declaration.

    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Richard Guy Briggs <rgb@redhat.com>
    CC: AKASHI Takahiro <takahiro.akashi@linaro.org>

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

commit 265e2a5de9955c87481f70b04936d0df5bff96c8
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

 arch/x86/platform/intel-mid/intel_mid_weak_decls.h |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

commit ed16dce6a39eadbdb4bf602838e1f4b7babdd2c0
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 7ca601442b56db657603588fc993ef9c1b5dd764
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 bd8d09cc9bbe817d7c7983e3490ed1ad2cda7b98
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 4e65950187eadf8a03e2746ef1c2696c20804d1d
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 48da6eae4e606af4f3280270e1c0fbf55e073d82
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 913d5138eb80aa9f6166dd954cc425c7b45be60e
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Oct 13 19:01:03 2014 -0600

    uprobes: Remove "weak" from function declarations

    For the following interfaces:

      set_swbp()
      set_orig_insn()
      is_swbp_insn()
      is_trap_insn()
      uprobe_get_swbp_addr()
      arch_uprobe_ignore()
      arch_uprobe_copy_ixol()

    kernel/events/uprobes.c provides default definitions explicitly marked
    "weak".  Some architectures provide their own definitions intended to
    override the defaults, but the "weak" attribute on the declarations 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 declarations so we always prefer a
    non-weak definition over the weak one, independent of link order.

    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    CC: Victor Kamensky <victor.kamensky@linaro.org>
    CC: Oleg Nesterov <oleg@redhat.com>
    CC: David A. Long <dave.long@linaro.org>
    CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

 include/linux/uprobes.h |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

commit 97c0521a8c4539f6b1fcda60fec71f7be0a999cd
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Wed Oct 22 13:47:18 2014 -0700

    hyperv: Fix the total_data_buflen in send path

    total_data_buflen is used by netvsc_send() to decide if a packet can be put
    into send buffer. It should also include the size of RNDIS message before the
    Ethernet frame. Otherwise, a messge with total size bigger than send_section_size
    may be copied into the send buffer, and cause data corruption.

    [Request to include this patch to the Stable branches]

    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

 drivers/net/hyperv/netvsc_drv.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

commit ddf93cb678c4734e44a6fad75bf46724f259170c
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 e92f812a8c4803671f26b873c20eb42a04b8b1c0
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

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

commit 03be4ee8796d95c56d66404785653e3f9dd35eec
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Oct 20 13:49:17 2014 +0200

    net: make skb_gso_segment error handling more robust

    skb_gso_segment has three possible return values:
    1. a pointer to the first segmented skb
    2. an errno value (IS_ERR())
    3. NULL.  This can happen when GSO is used for header verification.

    However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
    and would oops when NULL is returned.

    Note that these call sites should never actually see such a NULL return
    value; all callers mask out the GSO bits in the feature argument.

    However, there have been issues with some protocol handlers erronously not
    respecting the specified feature mask in some cases.

    It is preferable to get 'have to turn off hw offloading, else slow' reports
    rather than 'kernel crashes'.

    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

 net/ipv4/ip_output.c                 |    2 +-
 net/netfilter/nfnetlink_queue_core.c |    2 +-
 net/openvswitch/datapath.c           |    2 ++
 net/xfrm/xfrm_output.c               |    2 ++
 4 files changed, 6 insertions(+), 2 deletions(-)

commit 3ab31ee4d8c5ac9afcc43f180f60951cfc229014
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 7a5098fd68c6ec4e07b3114218f00839e440f8de
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 e93e26911de7070ad329336eddfd53aff42ba154
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 614044a9056cd6378df89f3ed40193ed3e336efc
Author: Brad Spengler <spender@grsecurity.net>
Date:   Wed Oct 22 18:19:01 2014 -0400

    hold sighand lock while accessing ->signal

    Conflicts:

    	fs/proc/array.c

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

Signature-tree: a4654efbdeeff749e74f6660472fc6aa9b9792d2