grsec: Apply grsecurity-3.0-3.17.7-201412211910.patch

commit 4435991915e5b4ab6ed45d79d645d908e151ac55
Author: Brad Spengler <spender@grsecurity.net>
Date:   Sun Dec 21 17:28:43 2014 -0500

    compile fix

 arch/x86/kernel/espfix_64.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

commit 3ddee99dda3c76e47ae4719ea8cb432020eca31a
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Fri Dec 5 19:03:28 2014 -0800

    x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit

    paravirt_enabled has the following effects:

     - Disables the F00F bug workaround warning.  There is no F00F bug
       workaround any more because Linux's standard IDT handling already
       works around the F00F bug, but the warning still exists.  This
       is only cosmetic, and, in any event, there is no such thing as
       KVM on a CPU with the F00F bug.

     - Disables 32-bit APM BIOS detection.  On a KVM paravirt system,
       there should be no APM BIOS anyway.

     - Disables tboot.  I think that the tboot code should check the
       CPUID hypervisor bit directly if it matters.

     - paravirt_enabled disables espfix32.  espfix32 should *not* be
       disabled under KVM paravirt.

    The last point is the purpose of this patch.  It fixes a leak of the
    high 16 bits of the kernel stack address on 32-bit KVM paravirt
    guests.  Fixes CVE-2014-8134.

    Cc: stable@vger.kernel.org
    Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

 arch/x86/kernel/kvm.c      |    9 ++++++++-
 arch/x86/kernel/kvmclock.c |    1 -
 2 files changed, 8 insertions(+), 2 deletions(-)

commit 50ebd6166caa35db5b36989aa0bb7e8cd46bc12c
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed Dec 17 14:48:30 2014 -0800

    x86/tls: Don't validate lm in set_thread_area() after all

    It turns out that there's a lurking ABI issue.  GCC, when
    compiling this in a 32-bit program:

    struct user_desc desc = {
    	.entry_number    = idx,
    	.base_addr       = base,
    	.limit           = 0xfffff,
    	.seg_32bit       = 1,
    	.contents        = 0, /* Data, grow-up */
    	.read_exec_only  = 0,
    	.limit_in_pages  = 1,
    	.seg_not_present = 0,
    	.useable         = 0,
    };

    will leave .lm uninitialized.  This means that anything in the
    kernel that reads user_desc.lm for 32-bit tasks is unreliable.

    Revert the .lm check in set_thread_area().  The value never did
    anything in the first place.

    Fixes: 0e58af4e1d21 ("x86/tls: Disallow unusual TLS segments")
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org # Only if 0e58af4e1d21 is backported
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

 arch/x86/include/uapi/asm/ldt.h |    7 +++++++
 arch/x86/kernel/tls.c           |    6 ------
 2 files changed, 7 insertions(+), 6 deletions(-)

commit 0021bd1dc91c9230cabd959c040a516da99b6a70
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Dec 4 16:48:17 2014 -0800

    x86/tls: Disallow unusual TLS segments

    Users have no business installing custom code segments into the
    GDT, and segments that are not present but are otherwise valid
    are a historical source of interesting attacks.

    For completeness, block attempts to set the L bit.  (Prior to
    this patch, the L bit would have been silently dropped.)

    This is an ABI break.  I've checked glibc, musl, and Wine, and
    none of them look like they'll have any trouble.

    Note to stable maintainers: this is a hardening patch that fixes
    no known bugs.  Given the possibility of ABI issues, this
    probably shouldn't be backported quickly.

    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: stable@vger.kernel.org # optional
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: security@kernel.org <security@kernel.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

 arch/x86/kernel/tls.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

commit 080d7d65711e4c96d6393fff9223ace6a0162b8b
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Dec 4 16:48:16 2014 -0800

    x86/tls: Validate TLS entries to protect espfix

    Installing a 16-bit RW data segment into the GDT defeats espfix.
    AFAICT this will not affect glibc, Wine, or dosemu at all.

    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: stable@vger.kernel.org
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: security@kernel.org <security@kernel.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

 arch/x86/kernel/tls.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

commit 60ef5002e1dc5cf436df8d9f6b5882354308a7e0
Author: Brad Spengler <spender@grsecurity.net>
Date:   Sun Dec 21 16:32:08 2014 -0500

    Fix a long-standing incompatibility between x64 UDEREF and CONFIG_PARAVIRT
    on PCID-capable systems.  Generally it resulted in userland crashes preventing
    boot of the system which were able to be worked around by booting with nopcid
    and receiving a weaker UDEREF implementation.  The source of the problem
    was paravirt-specific asm alternatives for flush_tlb_single rewriting the
    pv_mm_ops's native code with a single invlpg.

    As of this patch, no recommendations should be made to boot with nopcid, as
    it results in a weaker UDEREF implementation.

 arch/x86/kernel/paravirt_patch_64.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

commit ff46fb93ffba1506ff56637e28d75b0cfa8b4901
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Sun Nov 2 11:54:52 2014 +0200

    KVM: x86: MOV to CR3 can set bit 63

    Although Intel SDM mentions bit 63 is reserved, MOV to CR3 can have bit 63 set.
    As Intel SDM states in section 4.10.4 "Invalidation of TLBs and
    Paging-Structure Caches": " MOV to CR3. ... If CR4.PCIDE = 1 and bit 63 of the
    instructionâ€™s source operand is 0 ..."

    In other words, bit 63 is not reserved. KVM emulator currently consider bit 63
    as reserved. Fix it.

    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 |    1 +
 arch/x86/kvm/emulate.c          |    2 +-
 arch/x86/kvm/x86.c              |    2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

commit 9e8d317bf5702db18f35451dd986f8d1b6f22766
Author: Brad Spengler <spender@grsecurity.net>
Date:   Sat Dec 20 11:50:30 2014 -0500

    force off X86_16BIT if grsecurity is enabled -- nobody cares about
    running Windows 3.1 apps under wine, it's not worth the risk

 arch/x86/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

commit e5d12973adec885b3bb3938387d0fa46f4a1de8b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Dec 19 06:20:59 2014 +0000

    Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with l2cap socket

    same story as cmtp

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

 net/bluetooth/bnep/core.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

commit 2144f9994a7028d81122a306272a9891ee254474
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Dec 19 06:20:58 2014 +0000

    Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with l2cap socket

    ... rather than relying on ciptool(8) never passing it anything else.  Give
    it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops,
    trying to evaluate &l2cap_pi(sock->sk)->chan->dst...

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

 net/bluetooth/cmtp/core.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

commit eb77df555c6114324af1204e0882da0be274cd92
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Dec 19 06:20:57 2014 +0000

    Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

    it's OK after we'd verified the sockets, but not before that.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

 net/bluetooth/hidp/core.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

commit df54837b6210c2ebc404618b052052aa6b186214
Author: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Date:   Wed Dec 10 14:19:53 2014 +0200

    Bluetooth: 6lowpan: Do not free skb when packet is dropped

    If we need to drop the message because of some error in the
    compression etc, then do not free the skb as that is done
    automatically in other part of networking stack.

    Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

 net/bluetooth/6lowpan.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

commit 5948f7c10baa9d96f95b14b504a87cb763fbcd3b
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 18 10:57:19 2014 -0600

    mnt: Fix a memory stomp in umount

    While reviewing the code of umount_tree I realized that when we append
    to a preexisting unmounted list we do not change pprev of the former
    first item in the list.

    Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on
    the former first item of the list will stomp unmounted.first leaving
    it set to some random mount point which we are likely to free soon.

    This isn't likely to hit, but if it does I don't know how anyone could
    track it down.

    [ This happened because we don't have all the same operations for
      hlist's as we do for normal doubly-linked lists. In particular,
      list_splice() is easy on our standard doubly-linked lists, while
      hlist_splice() doesn't exist and needs both start/end entries of the
      hlist.  And commit 38129a13e6e7 incorrectly open-coded that missing
      hlist_splice().

      We should think about making these kinds of "mindless" conversions
      easier to get right by adding the missing hlist helpers   - Linus ]

    Fixes: 38129a13e6e71f666e0468e99fdd932a687b4d7e switch mnt_hash to hlist
    Cc: stable@vger.kernel.org
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

 fs/namespace.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

commit 0316f1732b50dd3abd23be4d25147eded9c293e3
Author: Frank Praznik <frank.praznik@oh.rr.com>
Date:   Wed Nov 12 14:10:09 2014 -0500

    HID: sony: Use kernel allocated buffers for HID reports

    Replace stack buffers with kernel allocated buffers for sending
    and receiving HID reports to prevent issues with DMA transfers
    on certain hardware.

    Output report buffers are allocated at initialization time to avoid
    excessive calls to kmalloc and kfree.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=87991
    Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
    Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

 drivers/hid/hid-sony.c |  147 +++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 113 insertions(+), 34 deletions(-)

commit 182dd5b3de81d40f738573bb8c65e5ff946a1040
Author: Brad Spengler <spender@grsecurity.net>
Date:   Wed Dec 17 18:30:48 2014 -0500

    make the statically allocated pud page read-only while we're at it

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

commit 5cdec75a0eabd70dd3e9a046b561d205ef4ea492
Author: Brad Spengler <spender@grsecurity.net>
Date:   Wed Dec 17 18:28:16 2014 -0500

    Fix doublefault in espfix code when PAX_PER_CPU_PGD is enabled,
    reported by Andy Lutomirski

 arch/x86/kernel/espfix_64.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

commit 2f69df693a08003037f418a68d01b600633f51df
Author: Jan Kara <jack@suse.cz>
Date:   Mon Dec 15 14:22:46 2014 +0100

    isofs: Fix infinite looping over CE entries

    Rock Ridge extensions define so called Continuation Entries (CE) which
    define where is further space with Rock Ridge data. Corrupted isofs
    image can contain arbitrarily long chain of these, including a one
    containing loop and thus causing kernel to end in an infinite loop when
    traversing these entries.

    Limit the traversal to 32 entries which should be more than enough space
    to store all the Rock Ridge data.

    Reported-by: P J P <ppandit@redhat.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>

 fs/isofs/rock.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Signature-tree: b0521b281b986b613fed5f4b758ba58fdc116ea3