1. 11 May, 2016 3 commits
    • Marco Angaroni's avatar
      ipvs: correct initial offset of Call-ID header search in SIP persistence engine · 72faba32
      Marco Angaroni authored
      commit 7617a24f upstream.
      
      The IPVS SIP persistence engine is not able to parse the SIP header
      "Call-ID" when such header is inserted in the first positions of
      the SIP message.
      
      When IPVS is configured with "--pe sip" option, like for example:
      ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
      some particular messages (see below for details) do not create entries
      in the connection template table, which can be listed with:
      ipvsadm -Lcn --persistent-conn
      
      Problematic SIP messages are SIP responses having "Call-ID" header
      positioned just after message first line:
      SIP/2.0 200 OK
      [Call-ID header here]
      [rest of the headers]
      
      When "Call-ID" header is positioned down (after a few other headers)
      it is correctly recognized.
      
      This is due to the data offset used in get_callid function call inside
      ip_vs_pe_sip.c file: since dptr already points to the start of the
      SIP message, the value of dataoff should be initially 0.
      Otherwise the header is searched starting from some bytes after the
      first character of the SIP message.
      
      Fixes: 758ff033 ("IPVS: sip persistence engine")
      Signed-off-by: default avatarMarco Angaroni <marcoangaroni@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      72faba32
    • Behan Webster's avatar
      x86: LLVMLinux: Fix "incomplete type const struct x86cpu_device_id" · 376539fa
      Behan Webster authored
      commit c4586256 upstream.
      
      Similar to the fix in 40413dcb
      
      MODULE_DEVICE_TABLE(x86cpu, ...) expects the struct to be called struct
      x86cpu_device_id, and not struct x86_cpu_id which is what is used in the rest
      of the kernel code.  Although gcc seems to ignore this error, clang fails
      without this define to fix the name.
      
      Code from drivers/thermal/x86_pkg_temp_thermal.c
      static const struct x86_cpu_id __initconst pkg_temp_thermal_ids[] = { ... };
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      
      Error from clang:
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: error: variable has
            incomplete type 'const struct x86cpu_device_id'
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      ^
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:32: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                                     ^
      <scratch space>:143:1: note: expanded from here
      __mod_x86cpu_device_table
      ^
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: note: forward declaration of
            'struct x86cpu_device_id'
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:21: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                          ^
      <scratch space>:141:1: note: expanded from here
      x86cpu_device_id
      ^
      1 error generated.
      Signed-off-by: default avatarBehan Webster <behanw@converseincode.com>
      Signed-off-by: default avatarJan-Simon Möller <dl9pf@gmx.de>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [added vmbus, mei, and rapdio #defines, needed for 3.14 - gregkh]
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      376539fa
    • Paolo Bonzini's avatar
      compiler-gcc: disable -ftracer for __noclone functions · 0a0ff4eb
      Paolo Bonzini authored
      commit 95272c29 upstream.
      
      -ftracer can duplicate asm blocks causing compilation to fail in
      noclone functions.  For example, KVM declares a global variable
      in an asm like
      
          asm("2: ... \n
               .pushsection data \n
               .global vmx_return \n
               vmx_return: .long 2b");
      
      and -ftracer causes a double declaration.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: stable@vger.kernel.org
      Cc: kvm@vger.kernel.org
      Reported-by: default avatarLinda Walsh <lkml@tlinx.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0a0ff4eb
  2. 03 May, 2016 16 commits
  3. 02 May, 2016 14 commits
  4. 23 Apr, 2016 7 commits
    • Jiri Slaby's avatar
      Linux 3.12.59 · 0fd090c8
      Jiri Slaby authored
      0fd090c8
    • Andrew Honig's avatar
      KVM: x86: Reload pit counters for all channels when restoring state · e31a2100
      Andrew Honig authored
      commit 0185604c upstream.
      
      Currently if userspace restores the pit counters with a count of 0
      on channels 1 or 2 and the guest attempts to read the count on those
      channels, then KVM will perform a mod of 0 and crash.  This will ensure
      that 0 values are converted to 65536 as per the spec.
      
      This is CVE-2015-7513.
      Signed-off-by: default avatarAndy Honig <ahonig@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e31a2100
    • Saurabh Sengar's avatar
      KVM: x86: removing unused variable · 979e5410
      Saurabh Sengar authored
      commit 2da29bcc upstream.
      
      removing unused variables, found by coccinelle
      Signed-off-by: default avatarSaurabh Sengar <saurabh.truth@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      979e5410
    • Ryan Ware's avatar
      EVM: Use crypto_memneq() for digest comparisons · afe5a791
      Ryan Ware authored
      commit 613317bd upstream.
      
      This patch fixes vulnerability CVE-2016-2085.  The problem exists
      because the vm_verify_hmac() function includes a use of memcmp().
      Unfortunately, this allows timing side channel attacks; specifically
      a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
      the memcmp() to the cryptographically safe crypto_memneq().
      Reported-by: default avatarXiaofei Rex Guo <xiaofei.rex.guo@intel.com>
      Signed-off-by: default avatarRyan Ware <ware@linux.intel.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      afe5a791
    • James Yonan's avatar
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · d68e944a
      James Yonan authored
      commit 6bf37e5a upstream.
      
      When comparing MAC hashes, AEAD authentication tags, or other hash
      values in the context of authentication or integrity checking, it
      is important not to leak timing information to a potential attacker,
      i.e. when communication happens over a network.
      
      Bytewise memory comparisons (such as memcmp) are usually optimized so
      that they return a nonzero value as soon as a mismatch is found. E.g,
      on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
      and up to ~850 cyc for a full match (cold). This early-return behavior
      can leak timing information as a side channel, allowing an attacker to
      iteratively guess the correct result.
      
      This patch adds a new method crypto_memneq ("memory not equal to each
      other") to the crypto API that compares memory areas of the same length
      in roughly "constant time" (cache misses could change the timing, but
      since they don't reveal information about the content of the strings
      being compared, they are effectively benign). Iow, best and worst case
      behaviour take the same amount of time to complete (in contrast to
      memcmp).
      
      Note that crypto_memneq (unlike memcmp) can only be used to test for
      equality or inequality, NOT for lexicographical order. This, however,
      is not an issue for its use-cases within the crypto API.
      
      We tried to locate all of the places in the crypto API where memcmp was
      being used for authentication or integrity checking, and convert them
      over to crypto_memneq.
      
      crypto_memneq is declared noinline, placed in its own source file,
      and compiled with optimizations that might increase code size disabled
      ("Os") because a smart compiler (or LTO) might notice that the return
      value is always compared against zero/nonzero, and might then
      reintroduce the same early-return optimization that we are trying to
      avoid.
      
      Using #pragma or __attribute__ optimization annotations of the code
      for disabling optimization was avoided as it seems to be considered
      broken or unmaintained for long time in GCC [1]. Therefore, we work
      around that by specifying the compile flag for memneq.o directly in
      the Makefile. We found that this seems to be most appropriate.
      
      As we use ("Os"), this patch also provides a loop-free "fast-path" for
      frequently used 16 byte digests. Similarly to kernel library string
      functions, leave an option for future even further optimized architecture
      specific assembler implementations.
      
      This was a joint work of James Yonan and Daniel Borkmann. Also thanks
      for feedback from Florian Weimer on this and earlier proposals [2].
      
        [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
        [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: default avatarJames Yonan <james@openvpn.net>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d68e944a
    • David Howells's avatar
      KEYS: Fix handling of stored error in a negatively instantiated user key · 15216848
      David Howells authored
      commit 096fe9ea upstream.
      
      If a user key gets negatively instantiated, an error code is cached in the
      payload area.  A negatively instantiated key may be then be positively
      instantiated by updating it with valid data.  However, the ->update key
      type method must be aware that the error code may be there.
      
      The following may be used to trigger the bug in the user key type:
      
          keyctl request2 user user "" @u
          keyctl add user user "a" @u
      
      which manifests itself as:
      
      	BUG: unable to handle kernel paging request at 00000000ffffff8a
      	IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
      	PGD 7cc30067 PUD 0
      	Oops: 0002 [#1] SMP
      	Modules linked in:
      	CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      	task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000
      	RIP: 0010:[<ffffffff810a376f>]  [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
      	 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
      	RSP: 0018:ffff88003dd8bdb0  EFLAGS: 00010246
      	RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001
      	RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82
      	RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000
      	R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82
      	R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700
      	FS:  0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      	CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0
      	Stack:
      	 ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
      	 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
      	 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
      	Call Trace:
      	 [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
      	 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
      	 [<     inline     >] __key_update security/keys/key.c:730
      	 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
      	 [<     inline     >] SYSC_add_key security/keys/keyctl.c:125
      	 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
      	 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185
      
      Note the error code (-ENOKEY) in EDX.
      
      A similar bug can be tripped by:
      
          keyctl request2 trusted user "" @u
          keyctl add trusted user "a" @u
      
      This should also affect encrypted keys - but that has to be correctly
      parameterised or it will fail with EINVAL before getting to the bit that
      will crashes.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      15216848
    • Eric W. Biederman's avatar
      mnt: Move the clear of MNT_LOCKED from copy_tree to it's callers. · d26388bb
      Eric W. Biederman authored
      commit 8486a788 upstream.
      
      Clear MNT_LOCKED in the callers of copy_tree except copy_mnt_ns, and
      collect_mounts.  In copy_mnt_ns it is necessary to create an exact
      copy of a mount tree, so not clearing MNT_LOCKED is important.
      Similarly collect_mounts is used to take a snapshot of the mount tree
      for audit logging purposes and auditing using a faithful copy of the
      tree is important.
      
      This becomes particularly significant when we start setting MNT_LOCKED
      on rootfs to prevent it from being unmounted.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d26388bb