1. 30 Sep, 2016 10 commits
    • Ard Biesheuvel's avatar
      crypto: arm/aes-ctr - fix NULL dereference in tail processing · 9246fd26
      Ard Biesheuvel authored
      commit f82e90b2 upstream.
      
      The AES-CTR glue code avoids calling into the blkcipher API for the
      tail portion of the walk, by comparing the remainder of walk.nbytes
      modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
      into the tail processing block if they are equal. This tail processing
      block checks whether nbytes != 0, and does nothing otherwise.
      
      However, in case of an allocation failure in the blkcipher layer, we
      may enter this code with walk.nbytes == 0, while nbytes > 0. In this
      case, we should not dereference the source and destination pointers,
      since they may be NULL. So instead of checking for nbytes != 0, check
      for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
      non-error conditions.
      
      Fixes: 86464859 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
      Reported-by: default avatarxiakaixu <xiakaixu@huawei.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9246fd26
    • Ard Biesheuvel's avatar
      crypto: arm64/aes-ctr - fix NULL dereference in tail processing · 3e2d986d
      Ard Biesheuvel authored
      commit 2db34e78 upstream.
      
      The AES-CTR glue code avoids calling into the blkcipher API for the
      tail portion of the walk, by comparing the remainder of walk.nbytes
      modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
      into the tail processing block if they are equal. This tail processing
      block checks whether nbytes != 0, and does nothing otherwise.
      
      However, in case of an allocation failure in the blkcipher layer, we
      may enter this code with walk.nbytes == 0, while nbytes > 0. In this
      case, we should not dereference the source and destination pointers,
      since they may be NULL. So instead of checking for nbytes != 0, check
      for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
      non-error conditions.
      
      Fixes: 49788fe2 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
      Reported-by: default avatarxiakaixu <xiakaixu@huawei.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e2d986d
    • Eric Dumazet's avatar
      tcp: properly scale window in tcp_v[46]_reqsk_send_ack() · c867a112
      Eric Dumazet authored
      [ Upstream commit 20a2b49f ]
      
      When sending an ack in SYN_RECV state, we must scale the offered
      window if wscale option was negotiated and accepted.
      
      Tested:
       Following packetdrill test demonstrates the issue :
      
      0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
      +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
      
      +0 bind(3, ..., ...) = 0
      +0 listen(3, 1) = 0
      
      // Establish a connection.
      +0 < S 0:0(0) win 20000 <mss 1000,sackOK,wscale 7, nop, TS val 100 ecr 0>
      +0 > S. 0:0(0) ack 1 win 28960 <mss 1460,sackOK, TS val 100 ecr 100, nop, wscale 7>
      
      +0 < . 1:11(10) ack 1 win 156 <nop,nop,TS val 99 ecr 100>
      // check that window is properly scaled !
      +0 > . 1:1(0) ack 1 win 226 <nop,nop,TS val 200 ecr 100>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      c867a112
    • Eric Dumazet's avatar
      tcp: fix use after free in tcp_xmit_retransmit_queue() · 0f55fa75
      Eric Dumazet authored
      [ Upstream commit bb1fceca ]
      
      When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
      tail of the write queue using tcp_add_write_queue_tail()
      
      Then it attempts to copy user data into this fresh skb.
      
      If the copy fails, we undo the work and remove the fresh skb.
      
      Unfortunately, this undo lacks the change done to tp->highest_sack and
      we can leave a dangling pointer (to a freed skb)
      
      Later, tcp_xmit_retransmit_queue() can dereference this pointer and
      access freed memory. For regular kernels where memory is not unmapped,
      this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
      returning garbage instead of tp->snd_nxt, but with various debug
      features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.
      
      This bug was found by Marco Grassi thanks to syzkaller.
      
      Fixes: 6859d494 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
      Reported-by: default avatarMarco Grassi <marco.gra@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Reviewed-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      0f55fa75
    • Artem Germanov's avatar
      tcp: cwnd does not increase in TCP YeAH · 98418550
      Artem Germanov authored
      [ Upstream commit db7196a0 ]
      
      Commit 76174004
      (tcp: do not slow start when cwnd equals ssthresh )
      introduced regression in TCP YeAH. Using 100ms delay 1% loss virtual
      ethernet link kernel 4.2 shows bandwidth ~500KB/s for single TCP
      connection and kernel 4.3 and above (including 4.8-rc4) shows bandwidth
      ~100KB/s.
         That is caused by stalled cwnd when cwnd equals ssthresh. This patch
      fixes it by proper increasing cwnd in this case.
      Signed-off-by: default avatarArtem Germanov <agermanov@anchorfree.com>
      Acked-by: default avatarDmitry Adamushko <d.adamushko@anchorfree.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      98418550
    • Dave Jones's avatar
      ipv6: release dst in ping_v6_sendmsg · ea7dd213
      Dave Jones authored
      [ Upstream commit 03c2778a ]
      
      Neither the failure or success paths of ping_v6_sendmsg release
      the dst it acquires.  This leads to a flood of warnings from
      "net/core/dst.c:288 dst_release" on older kernels that
      don't have 8bf4ada2 backported.
      
      That patch optimistically hoped this had been fixed post 3.10, but
      it seems at least one case wasn't, where I've seen this triggered
      a lot from machines doing unprivileged icmp sockets.
      
      Cc: Martin Lau <kafai@fb.com>
      Signed-off-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      ea7dd213
    • David Forster's avatar
      ipv4: panic in leaf_walk_rcu due to stale node pointer · 6b8076b8
      David Forster authored
      [ Upstream commit 94d9f1c5 ]
      
      Panic occurs when issuing "cat /proc/net/route" whilst
      populating FIB with > 1M routes.
      
      Use of cached node pointer in fib_route_get_idx is unsafe.
      
       BUG: unable to handle kernel paging request at ffffc90001630024
       IP: [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
       PGD 11b08d067 PUD 11b08e067 PMD dac4b067 PTE 0
       Oops: 0000 [#1] SMP
       Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscac
       snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep virti
       acpi_cpufreq button parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd
      tio_ring virtio floppy uhci_hcd ehci_hcd usbcore usb_common libata scsi_mod
       CPU: 1 PID: 785 Comm: cat Not tainted 4.2.0-rc8+ #4
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
       task: ffff8800da1c0bc0 ti: ffff88011a05c000 task.ti: ffff88011a05c000
       RIP: 0010:[<ffffffff814cf6a0>]  [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
       RSP: 0018:ffff88011a05fda0  EFLAGS: 00010202
       RAX: ffff8800d8a40c00 RBX: ffff8800da4af940 RCX: ffff88011a05ff20
       RDX: ffffc90001630020 RSI: 0000000001013531 RDI: ffff8800da4af950
       RBP: 0000000000000000 R08: ffff8800da1f9a00 R09: 0000000000000000
       R10: ffff8800db45b7e4 R11: 0000000000000246 R12: ffff8800da4af950
       R13: ffff8800d97a74c0 R14: 0000000000000000 R15: ffff8800d97a7480
       FS:  00007fd3970e0700(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffffc90001630024 CR3: 000000011a7e4000 CR4: 00000000000006e0
       Stack:
        ffffffff814d00d3 0000000000000000 ffff88011a05ff20 ffff8800da1f9a00
        ffffffff811dd8b9 0000000000000800 0000000000020000 00007fd396f35000
        ffffffff811f8714 0000000000003431 ffffffff8138dce0 0000000000000f80
       Call Trace:
        [<ffffffff814d00d3>] ? fib_route_seq_start+0x93/0xc0
        [<ffffffff811dd8b9>] ? seq_read+0x149/0x380
        [<ffffffff811f8714>] ? fsnotify+0x3b4/0x500
        [<ffffffff8138dce0>] ? process_echoes+0x70/0x70
        [<ffffffff8121cfa7>] ? proc_reg_read+0x47/0x70
        [<ffffffff811bb823>] ? __vfs_read+0x23/0xd0
        [<ffffffff811bbd42>] ? rw_verify_area+0x52/0xf0
        [<ffffffff811bbe61>] ? vfs_read+0x81/0x120
        [<ffffffff811bcbc2>] ? SyS_read+0x42/0xa0
        [<ffffffff81549ab2>] ? entry_SYSCALL_64_fastpath+0x16/0x75
       Code: 48 85 c0 75 d8 f3 c3 31 c0 c3 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00
      a 04 89 f0 33 02 44 89 c9 48 d3 e8 0f b6 4a 05 49 89
       RIP  [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
        RSP <ffff88011a05fda0>
       CR2: ffffc90001630024
      Signed-off-by: default avatarDave Forster <dforster@brocade.com>
      Acked-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      6b8076b8
    • Jeff Mahoney's avatar
      reiserfs: fix "new_insert_key may be used uninitialized ..." · daef25aa
      Jeff Mahoney authored
      commit 0a11b9aa upstream.
      
      new_insert_key only makes any sense when it's associated with a
      new_insert_ptr, which is initialized to NULL and changed to a
      buffer_head when we also initialize new_insert_key.  We can key off of
      that to avoid the uninitialized warning.
      
      Link: http://lkml.kernel.org/r/5eca5ffb-2155-8df2-b4a2-f162f105efed@suse.comSigned-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daef25aa
    • Arnd Bergmann's avatar
      Fix build warning in kernel/cpuset.c · 29bd0359
      Arnd Bergmann authored
      >           2 ../kernel/cpuset.c:2101:11: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
      >           1 ../kernel/cpuset.c:2101:2: warning: initialization from incompatible pointer type
      >           1 ../kernel/cpuset.c:2101:2: warning: (near initialization for 'cpuset_cgrp_subsys.fork')
      
      This got introduced by 06ec7a1d ("cpuset: make sure new tasks
      conform to the current config of the cpuset"). In the upstream
      kernel, the function prototype was changed as of b53202e6
      ("cgroup: kill cgrp_ss_priv[CGROUP_CANFORK_COUNT] and friends").
      
      That patch is not suitable for stable kernels, and fortunately
      the warning seems harmless as the prototypes only differ in the
      second argument that is unused. Adding that argument gets rid
      of the warning:
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29bd0359
    • Michal Nazarewicz's avatar
      include/linux/kernel.h: change abs() macro so it uses consistent return type · df127725
      Michal Nazarewicz authored
      commit 8f57e4d9 upstream.
      
      Rewrite abs() so that its return type does not depend on the
      architecture and no unexpected type conversion happen inside of it.  The
      only conversion is from unsigned to signed type.  char is left as a
      return type but treated as a signed type regradless of it's actual
      signedness.
      
      With the old version, int arguments were promoted to long and depending
      on architecture a long argument might result in s64 or long return type
      (which may or may not be the same).
      
      This came after some back and forth with Nicolas.  The current macro has
      different return type (for the same input type) depending on
      architecture which might be midly iritating.
      
      An alternative version would promote to int like so:
      
      	#define abs(x)	__abs_choose_expr(x, long long,			\
      			__abs_choose_expr(x, long,			\
      			__builtin_choose_expr(				\
      				sizeof(x) <= sizeof(int),		\
      				({ int __x = (x); __x<0?-__x:__x; }),	\
      				((void)0))))
      
      I have no preference but imagine Linus might.  :] Nicolas argument against
      is that promoting to int causes iconsistent behaviour:
      
      	int main(void) {
      		unsigned short a = 0, b = 1, c = a - b;
      		unsigned short d = abs(a - b);
      		unsigned short e = abs(c);
      		printf("%u %u\n", d, e);  // prints: 1 65535
      	}
      
      Then again, no sane person expects consistent behaviour from C integer
      arithmetic.  ;)
      
      Note:
      
        __builtin_types_compatible_p(unsigned char, char) is always false, and
        __builtin_types_compatible_p(signed char, char) is also always false.
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df127725
  2. 24 Sep, 2016 30 commits