1. 18 Jul, 2017 8 commits
  2. 02 Jul, 2017 7 commits
    • Ben Hutchings's avatar
      Linux 3.2.90 · 9b733a81
      Ben Hutchings authored
      9b733a81
    • Mikulas Patocka's avatar
      mm: fix find_vma_prev · 0e49b7dd
      Mikulas Patocka authored
      commit 83cd904d upstream.
      
      Commit 6bd4837d ("mm: simplify find_vma_prev()") broke memory
      management on PA-RISC.
      
      After application of the patch, programs that allocate big arrays on the
      stack crash with segfault, for example, this will crash if compiled
      without optimization:
      
        int main()
        {
      	char array[200000];
      	array[199999] = 0;
      	return 0;
        }
      
      The reason is that PA-RISC has up-growing stack and the stack is usually
      the last memory area.  In the above example, a page fault happens above
      the stack.
      
      Previously, if we passed too high address to find_vma_prev, it returned
      NULL and stored the last VMA in *pprev.  After "simplify find_vma_prev"
      change, it stores NULL in *pprev.  Consequently, the stack area is not
      found and it is not expanded, as it used to be before the change.
      
      This patch restores the old behavior and makes it return the last VMA in
      *pprev if the requested address is higher than address of any other VMA.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0e49b7dd
    • KOSAKI Motohiro's avatar
      mm: simplify find_vma_prev() · 2e8d6ed8
      KOSAKI Motohiro authored
      commit 6bd4837d upstream.
      
      commit 297c5eee ("mm: make the vma list be doubly linked") added the
      vm_prev member to vm_area_struct.  We can simplify find_vma_prev() by
      using it.  Also, this change helps to improve page fault performance
      because it has stronger locality of reference.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2e8d6ed8
    • David Howells's avatar
      rxrpc: Fix several cases where a padded len isn't checked in ticket decode · 09c9faac
      David Howells authored
      commit 5f2f9765 upstream.
      
      This fixes CVE-2017-7482.
      
      When a kerberos 5 ticket is being decoded so that it can be loaded into an
      rxrpc-type key, there are several places in which the length of a
      variable-length field is checked to make sure that it's not going to
      overrun the available data - but the data is padded to the nearest
      four-byte boundary and the code doesn't check for this extra.  This could
      lead to the size-remaining variable wrapping and the data pointer going
      over the end of the buffer.
      
      Fix this by making the various variable-length data checks use the padded
      length.
      Reported-by: default avatar石磊 <shilei-c@360.cn>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.c.dionne@auristor.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      09c9faac
    • Helge Deller's avatar
      Allow stack to grow up to address space limit · a7d51947
      Helge Deller authored
      commit bd726c90 upstream.
      
      Fix expand_upwards() on architectures with an upward-growing stack (parisc,
      metag and partly IA-64) to allow the stack to reliably grow exactly up to
      the address space limit given by TASK_SIZE.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a7d51947
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · 640c7dfd
      Hugh Dickins authored
      commit 1be7107f upstream.
      
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [Hugh Dickins: Backported to 3.2]
      [bwh: Fix more instances of vma->vm_start in sparc64 impl. of
       arch_get_unmapped_area_topdown() and generic impl. of
       hugetlb_get_unmapped_area()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      640c7dfd
    • Linus Torvalds's avatar
      mm: do not grow the stack vma just because of an overrun on preceding vma · 641fbf59
      Linus Torvalds authored
      commit 09884964 upstream.
      
      The stack vma is designed to grow automatically (marked with VM_GROWSUP
      or VM_GROWSDOWN depending on architecture) when an access is made beyond
      the existing boundary.  However, particularly if you have not limited
      your stack at all ("ulimit -s unlimited"), this can cause the stack to
      grow even if the access was really just one past *another* segment.
      
      And that's wrong, especially since we first grow the segment, but then
      immediately later enforce the stack guard page on the last page of the
      segment.  So _despite_ first growing the stack segment as a result of
      the access, the kernel will then make the access cause a SIGSEGV anyway!
      
      So do the same logic as the guard page check does, and consider an
      access to within one page of the next segment to be a bad access, rather
      than growing the stack to abut the next segment.
      Reported-and-tested-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      641fbf59
  3. 05 Jun, 2017 25 commits
    • Ben Hutchings's avatar
      Linux 3.2.89 · 8ff47baf
      Ben Hutchings authored
      8ff47baf
    • Eric Dumazet's avatar
      ipv6: fix out of bound writes in __ip6_append_data() · e5238fca
      Eric Dumazet authored
      commit 232cd35d upstream.
      
      Andrey Konovalov and idaifish@gmail.com reported crashes caused by
      one skb shared_info being overwritten from __ip6_append_data()
      
      Andrey program lead to following state :
      
      copy -4200 datalen 2000 fraglen 2040
      maxfraglen 2040 alloclen 2048 transhdrlen 0 offset 0 fraggap 6200
      
      The skb_copy_and_csum_bits(skb_prev, maxfraglen, data + transhdrlen,
      fraggap, 0); is overwriting skb->head and skb_shared_info
      
      Since we apparently detect this rare condition too late, move the
      code earlier to even avoid allocating skb and risking crashes.
      
      Once again, many thanks to Andrey and syzkaller team.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Reported-by: <idaifish@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e5238fca
    • WANG Cong's avatar
      ipv6/dccp: do not inherit ipv6_mc_list from parent · 0767192a
      WANG Cong authored
      commit 83eaddab upstream.
      
      Like commit 657831ff ("dccp/tcp: do not inherit mc_list from parent")
      we should clear ipv6_mc_list etc. for IPv6 sockets too.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0767192a
    • Eric Dumazet's avatar
      sctp: do not inherit ipv6_{mc|ac|fl}_list from parent · cc1fa781
      Eric Dumazet authored
      commit fdcee2cb upstream.
      
      SCTP needs fixes similar to 83eaddab ("ipv6/dccp: do not inherit
      ipv6_mc_list from parent"), otherwise bad things can happen.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cc1fa781
    • David S. Miller's avatar
      ipv6: Check ip6_find_1stfragopt() return value properly. · f7c2d2d7
      David S. Miller authored
      commit 7dd7eb95 upstream.
      
      Do not use unsigned variables to see if it returns a negative
      error or not.
      
      Fixes: 2423496a ("ipv6: Prevent overrun when parsing v6 header options")
      Reported-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust filenames, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f7c2d2d7
    • Craig Gallek's avatar
      ipv6: Prevent overrun when parsing v6 header options · ad8a4d9d
      Craig Gallek authored
      commit 2423496a upstream.
      
      The KASAN warning repoted below was discovered with a syzkaller
      program.  The reproducer is basically:
        int s = socket(AF_INET6, SOCK_RAW, NEXTHDR_HOP);
        send(s, &one_byte_of_data, 1, MSG_MORE);
        send(s, &more_than_mtu_bytes_data, 2000, 0);
      
      The socket() call sets the nexthdr field of the v6 header to
      NEXTHDR_HOP, the first send call primes the payload with a non zero
      byte of data, and the second send call triggers the fragmentation path.
      
      The fragmentation code tries to parse the header options in order
      to figure out where to insert the fragment option.  Since nexthdr points
      to an invalid option, the calculation of the size of the network header
      can made to be much larger than the linear section of the skb and data
      is read outside of it.
      
      This fix makes ip6_find_1stfrag return an error if it detects
      running out-of-bounds.
      
      [   42.361487] ==================================================================
      [   42.364412] BUG: KASAN: slab-out-of-bounds in ip6_fragment+0x11c8/0x3730
      [   42.365471] Read of size 840 at addr ffff88000969e798 by task ip6_fragment-oo/3789
      [   42.366469]
      [   42.366696] CPU: 1 PID: 3789 Comm: ip6_fragment-oo Not tainted 4.11.0+ #41
      [   42.367628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
      [   42.368824] Call Trace:
      [   42.369183]  dump_stack+0xb3/0x10b
      [   42.369664]  print_address_description+0x73/0x290
      [   42.370325]  kasan_report+0x252/0x370
      [   42.370839]  ? ip6_fragment+0x11c8/0x3730
      [   42.371396]  check_memory_region+0x13c/0x1a0
      [   42.371978]  memcpy+0x23/0x50
      [   42.372395]  ip6_fragment+0x11c8/0x3730
      [   42.372920]  ? nf_ct_expect_unregister_notifier+0x110/0x110
      [   42.373681]  ? ip6_copy_metadata+0x7f0/0x7f0
      [   42.374263]  ? ip6_forward+0x2e30/0x2e30
      [   42.374803]  ip6_finish_output+0x584/0x990
      [   42.375350]  ip6_output+0x1b7/0x690
      [   42.375836]  ? ip6_finish_output+0x990/0x990
      [   42.376411]  ? ip6_fragment+0x3730/0x3730
      [   42.376968]  ip6_local_out+0x95/0x160
      [   42.377471]  ip6_send_skb+0xa1/0x330
      [   42.377969]  ip6_push_pending_frames+0xb3/0xe0
      [   42.378589]  rawv6_sendmsg+0x2051/0x2db0
      [   42.379129]  ? rawv6_bind+0x8b0/0x8b0
      [   42.379633]  ? _copy_from_user+0x84/0xe0
      [   42.380193]  ? debug_check_no_locks_freed+0x290/0x290
      [   42.380878]  ? ___sys_sendmsg+0x162/0x930
      [   42.381427]  ? rcu_read_lock_sched_held+0xa3/0x120
      [   42.382074]  ? sock_has_perm+0x1f6/0x290
      [   42.382614]  ? ___sys_sendmsg+0x167/0x930
      [   42.383173]  ? lock_downgrade+0x660/0x660
      [   42.383727]  inet_sendmsg+0x123/0x500
      [   42.384226]  ? inet_sendmsg+0x123/0x500
      [   42.384748]  ? inet_recvmsg+0x540/0x540
      [   42.385263]  sock_sendmsg+0xca/0x110
      [   42.385758]  SYSC_sendto+0x217/0x380
      [   42.386249]  ? SYSC_connect+0x310/0x310
      [   42.386783]  ? __might_fault+0x110/0x1d0
      [   42.387324]  ? lock_downgrade+0x660/0x660
      [   42.387880]  ? __fget_light+0xa1/0x1f0
      [   42.388403]  ? __fdget+0x18/0x20
      [   42.388851]  ? sock_common_setsockopt+0x95/0xd0
      [   42.389472]  ? SyS_setsockopt+0x17f/0x260
      [   42.390021]  ? entry_SYSCALL_64_fastpath+0x5/0xbe
      [   42.390650]  SyS_sendto+0x40/0x50
      [   42.391103]  entry_SYSCALL_64_fastpath+0x1f/0xbe
      [   42.391731] RIP: 0033:0x7fbbb711e383
      [   42.392217] RSP: 002b:00007ffff4d34f28 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [   42.393235] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbbb711e383
      [   42.394195] RDX: 0000000000001000 RSI: 00007ffff4d34f60 RDI: 0000000000000003
      [   42.395145] RBP: 0000000000000046 R08: 00007ffff4d34f40 R09: 0000000000000018
      [   42.396056] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400aad
      [   42.396598] R13: 0000000000000066 R14: 00007ffff4d34ee0 R15: 00007fbbb717af00
      [   42.397257]
      [   42.397411] Allocated by task 3789:
      [   42.397702]  save_stack_trace+0x16/0x20
      [   42.398005]  save_stack+0x46/0xd0
      [   42.398267]  kasan_kmalloc+0xad/0xe0
      [   42.398548]  kasan_slab_alloc+0x12/0x20
      [   42.398848]  __kmalloc_node_track_caller+0xcb/0x380
      [   42.399224]  __kmalloc_reserve.isra.32+0x41/0xe0
      [   42.399654]  __alloc_skb+0xf8/0x580
      [   42.400003]  sock_wmalloc+0xab/0xf0
      [   42.400346]  __ip6_append_data.isra.41+0x2472/0x33d0
      [   42.400813]  ip6_append_data+0x1a8/0x2f0
      [   42.401122]  rawv6_sendmsg+0x11ee/0x2db0
      [   42.401505]  inet_sendmsg+0x123/0x500
      [   42.401860]  sock_sendmsg+0xca/0x110
      [   42.402209]  ___sys_sendmsg+0x7cb/0x930
      [   42.402582]  __sys_sendmsg+0xd9/0x190
      [   42.402941]  SyS_sendmsg+0x2d/0x50
      [   42.403273]  entry_SYSCALL_64_fastpath+0x1f/0xbe
      [   42.403718]
      [   42.403871] Freed by task 1794:
      [   42.404146]  save_stack_trace+0x16/0x20
      [   42.404515]  save_stack+0x46/0xd0
      [   42.404827]  kasan_slab_free+0x72/0xc0
      [   42.405167]  kfree+0xe8/0x2b0
      [   42.405462]  skb_free_head+0x74/0xb0
      [   42.405806]  skb_release_data+0x30e/0x3a0
      [   42.406198]  skb_release_all+0x4a/0x60
      [   42.406563]  consume_skb+0x113/0x2e0
      [   42.406910]  skb_free_datagram+0x1a/0xe0
      [   42.407288]  netlink_recvmsg+0x60d/0xe40
      [   42.407667]  sock_recvmsg+0xd7/0x110
      [   42.408022]  ___sys_recvmsg+0x25c/0x580
      [   42.408395]  __sys_recvmsg+0xd6/0x190
      [   42.408753]  SyS_recvmsg+0x2d/0x50
      [   42.409086]  entry_SYSCALL_64_fastpath+0x1f/0xbe
      [   42.409513]
      [   42.409665] The buggy address belongs to the object at ffff88000969e780
      [   42.409665]  which belongs to the cache kmalloc-512 of size 512
      [   42.410846] The buggy address is located 24 bytes inside of
      [   42.410846]  512-byte region [ffff88000969e780, ffff88000969e980)
      [   42.411941] The buggy address belongs to the page:
      [   42.412405] page:ffffea000025a780 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
      [   42.413298] flags: 0x100000000008100(slab|head)
      [   42.413729] raw: 0100000000008100 0000000000000000 0000000000000000 00000001800c000c
      [   42.414387] raw: ffffea00002a9500 0000000900000007 ffff88000c401280 0000000000000000
      [   42.415074] page dumped because: kasan: bad access detected
      [   42.415604]
      [   42.415757] Memory state around the buggy address:
      [   42.416222]  ffff88000969e880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   42.416904]  ffff88000969e900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   42.417591] >ffff88000969e980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   42.418273]                    ^
      [   42.418588]  ffff88000969ea00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   42.419273]  ffff88000969ea80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   42.419882] ==================================================================
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCraig Gallek <kraig@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust filenames, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ad8a4d9d
    • Johan Hovold's avatar
      USB: serial: omninet: fix reference leaks at open · 8b236342
      Johan Hovold authored
      commit 30572418 upstream.
      
      This driver needlessly took another reference to the tty on open, a
      reference which was then never released on close. This lead to not just
      a leak of the tty, but also a driver reference leak that prevented the
      driver from being unloaded after a port had once been opened.
      
      Fixes: 4a90f09b ("tty: usb-serial krefs")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      [bwh: Backported to 3.2:
       - The 'serial' variable is still needed for other initialisation
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8b236342
    • Johan Hovold's avatar
      USB: serial: io_ti: fix information leak in completion handler · 6d0c5870
      Johan Hovold authored
      commit 654b404f upstream.
      
      Add missing sanity check to the bulk-in completion handler to avoid an
      integer underflow that can be triggered by a malicious device.
      
      This avoids leaking 128 kB of memory content from after the URB transfer
      buffer to user space.
      
      Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6d0c5870
    • Eric Dumazet's avatar
      dccp/tcp: do not inherit mc_list from parent · 3d221359
      Eric Dumazet authored
      commit 657831ff upstream.
      
      syzkaller found a way to trigger double frees from ip_mc_drop_socket()
      
      It turns out that leave a copy of parent mc_list at accept() time,
      which is very bad.
      
      Very similar to commit 8b485ce6 ("tcp: do not inherit
      fastopen_req from parent")
      
      Initial report from Pray3r, completed by Andrey one.
      Thanks a lot to them !
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarPray3r <pray3r.z@gmail.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3d221359
    • J. Bruce Fields's avatar
      nfsd: stricter decoding of write-like NFSv2/v3 ops · 6b9ba0c0
      J. Bruce Fields authored
      commit 13bf9fbf upstream.
      
      The NFSv2/v3 code does not systematically check whether we decode past
      the end of the buffer.  This generally appears to be harmless, but there
      are a few places where we do arithmetic on the pointers involved and
      don't account for the possibility that a length could be negative.  Add
      checks to catch these.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6b9ba0c0
    • J. Bruce Fields's avatar
      nfsd4: minor NFSv2/v3 write decoding cleanup · 4625f286
      J. Bruce Fields authored
      commit db44bac4 upstream.
      
      Use a couple shortcuts that will simplify a following bugfix.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      [bwh: Backported to 3.2: in nfs3svc_decode_writeargs(), dlen doesn't include
       tail]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4625f286
    • J. Bruce Fields's avatar
      nfsd: check for oversized NFSv2/v3 arguments · 1eb3e42d
      J. Bruce Fields authored
      commit e6838a29 upstream.
      
      A client can append random data to the end of an NFSv2 or NFSv3 RPC call
      without our complaining; we'll just stop parsing at the end of the
      expected data and ignore the rest.
      
      Encoded arguments and replies are stored together in an array of pages,
      and if a call is too large it could leave inadequate space for the
      reply.  This is normally OK because NFS RPC's typically have either
      short arguments and long replies (like READ) or long arguments and short
      replies (like WRITE).  But a client that sends an incorrectly long reply
      can violate those assumptions.  This was observed to cause crashes.
      
      Also, several operations increment rq_next_page in the decode routine
      before checking the argument size, which can leave rq_next_page pointing
      well past the end of the page array, causing trouble later in
      svc_free_pages.
      
      So, following a suggestion from Neil Brown, add a central check to
      enforce our expectation that no NFSv2/v3 call has both a large call and
      a large reply.
      
      As followup we may also want to rewrite the encoding routines to check
      more carefully that they aren't running off the end of the page array.
      
      We may also consider rejecting calls that have any extra garbage
      appended.  That would be safer, and within our rights by spec, but given
      the age of our server and the NFS protocol, and the fact that we've
      never enforced this before, we may need to balance that against the
      possibility of breaking some oddball client.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1eb3e42d
    • Dan Carpenter's avatar
      ipx: call ipxitf_put() in ioctl error path · 48dc185b
      Dan Carpenter authored
      commit ee0d8d84 upstream.
      
      We should call ipxitf_put() if the copy_to_user() fails.
      Reported-by: default avatar李强 <liqiang6-s@360.cn>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      48dc185b
    • Amey Telawane's avatar
      tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline() · e39e6419
      Amey Telawane authored
      commit e09e2867 upstream.
      
      Strcpy is inherently not safe, and strlcpy() should be used instead.
      __trace_find_cmdline() uses strcpy() because the comms saved must have a
      terminating nul character, but it doesn't hurt to add the extra protection
      of using strlcpy() instead of strcpy().
      
      Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.orgSigned-off-by: default avatarAmey Telawane <ameyt@codeaurora.org>
      [AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10
      https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477]
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      [ Updated change log and removed the "- 1" from len parameter ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e39e6419
    • Herbert Xu's avatar
      crypto: ahash - Fix EINPROGRESS notification callback · 82ef3e7b
      Herbert Xu authored
      commit ef0579b6 upstream.
      
      The ahash API modifies the request's callback function in order
      to clean up after itself in some corner cases (unaligned final
      and missing finup).
      
      When the request is complete ahash will restore the original
      callback and everything is fine.  However, when the request gets
      an EBUSY on a full queue, an EINPROGRESS callback is made while
      the request is still ongoing.
      
      In this case the ahash API will incorrectly call its own callback.
      
      This patch fixes the problem by creating a temporary request
      object on the stack which is used to relay EINPROGRESS back to
      the original completion function.
      
      This patch also adds code to preserve the original flags value.
      
      Fixes: ab6bf4e5 ("crypto: hash - Fix the pointer voodoo in...")
      Reported-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      82ef3e7b
    • Marek Vasut's avatar
      crypto: hash - Simplify the ahash_finup implementation · cb149762
      Marek Vasut authored
      commit d4a7a0fb upstream.
      
      The ahash_def_finup() can make use of the request save/restore functions,
      thus make it so. This simplifies the code a little and unifies the code
      paths.
      
      Note that the same remark about free()ing the req->priv applies here, the
      req->priv can only be free()'d after the original request was restored.
      
      Finally, squash a bug in the invocation of completion in the ASYNC path.
      In both ahash_def_finup_done{1,2}, the function areq->base.complete(X, err);
      was called with X=areq->base.data . This is incorrect , as X=&areq->base
      is the correct value. By analysis of the data structures, we see the areq is
      of type 'struct ahash_request' , areq->base is of type 'struct crypto_async_request'
      and areq->base.completion is of type crypto_completion_t, which is defined in
      include/linux/crypto.h as:
      
        typedef void (*crypto_completion_t)(struct crypto_async_request *req, int err);
      
      This is one lead that the X should be &areq->base . Next up, we can inspect
      other code which calls the completion callback to give us kind-of statistical
      idea of how this callback is used. We can try:
      
        $ git grep base\.complete\( drivers/crypto/
      
      Finally, by inspecting ahash_request_set_callback() implementation defined
      in include/crypto/hash.h , we observe that the .data entry of 'struct
      crypto_async_request' is intended for arbitrary data, not for completion
      argument.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cb149762
    • Marek Vasut's avatar
      crypto: hash - Pull out the functions to save/restore request · 2cd9fdcc
      Marek Vasut authored
      commit 1ffc9fbd upstream.
      
      The functions to save original request within a newly adjusted request
      and it's counterpart to restore the original request can be re-used by
      more code in the crypto/ahash.c file. Pull these functions out from the
      code so they're available.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2cd9fdcc
    • Marek Vasut's avatar
      crypto: hash - Fix the pointer voodoo in unaligned ahash · 7cd39b9d
      Marek Vasut authored
      commit ab6bf4e5 upstream.
      
      Add documentation for the pointer voodoo that is happening in crypto/ahash.c
      in ahash_op_unaligned(). This code is quite confusing, so add a beefy chunk
      of documentation.
      
      Moreover, make sure the mangled request is completely restored after finishing
      this unaligned operation. This means restoring all of .result, .base.data
      and .base.complete .
      
      Also, remove the crypto_completion_t complete = ... line present in the
      ahash_op_unaligned_done() function. This type actually declares a function
      pointer, which is very confusing.
      
      Finally, yet very important nonetheless, make sure the req->priv is free()'d
      only after the original request is restored in ahash_op_unaligned_done().
      The req->priv data must not be free()'d before that in ahash_op_unaligned_finish(),
      since we would be accessing previously free()'d data in ahash_op_unaligned_done()
      and cause corruption.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7cd39b9d
    • Marek Vasut's avatar
      crypto: ahash - Fully restore ahash request before completing · cf552375
      Marek Vasut authored
      commit 1d9a394b upstream.
      
      When finishing the ahash request, the ahash_op_unaligned_done() will
      call complete() on the request. Yet, this will not call the correct
      complete callback. The correct complete callback was previously stored
      in the requests' private data, as seen in ahash_op_unaligned(). This
      patch restores the correct complete callback and .data field of the
      request before calling complete() on it.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cf552375
    • Chris Salls's avatar
      mm/mempolicy.c: fix error handling in set_mempolicy and mbind. · 3f3b4a9d
      Chris Salls authored
      commit cf01fb99 upstream.
      
      In the case that compat_get_bitmap fails we do not want to copy the
      bitmap to the user as it will contain uninitialized stack data and leak
      sensitive data.
      Signed-off-by: default avatarChris Salls <salls@cs.ucsb.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3f3b4a9d
    • Eric Biggers's avatar
      KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings · 0ebd7208
      Eric Biggers authored
      commit c9f838d1 upstream.
      
      This fixes CVE-2017-7472.
      
      Running the following program as an unprivileged user exhausts kernel
      memory by leaking thread keyrings:
      
      	#include <keyutils.h>
      
      	int main()
      	{
      		for (;;)
      			keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
      	}
      
      Fix it by only creating a new thread keyring if there wasn't one before.
      To make things more consistent, make install_thread_keyring_to_cred()
      and install_process_keyring_to_cred() both return 0 if the corresponding
      keyring is already present.
      
      Fixes: d84f4f99 ("CRED: Inaugurate COW credentials")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0ebd7208
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for tp_reserve · 96053b29
      Andrey Konovalov authored
      commit bcc5364b upstream.
      
      When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
      
      Fix by checking that tp_reserve <= INT_MAX on assign.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      96053b29
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for tp_frame_nr · 16341722
      Andrey Konovalov authored
      commit 8f8d28e4 upstream.
      
      When calculating rb->frames_per_block * req->tp_block_nr the result
      can overflow.
      
      Add a check that tp_block_size * tp_block_nr <= UINT_MAX.
      
      Since frames_per_block <= tp_block_size, the expression would
      never overflow.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      16341722
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for priv area size · 091a6de0
      Andrey Konovalov authored
      commit 2b6867c2 upstream.
      
      Subtracting tp_sizeof_priv from tp_block_size and casting to int
      to check whether one is less then the other doesn't always work
      (both of them are unsigned ints).
      
      Compare them as is instead.
      
      Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as
      it can overflow inside BLK_PLUS_PRIV otherwise.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      091a6de0
    • Eric Dumazet's avatar
      packet: handle too big packets for PACKET_V3 · 7a57c268
      Eric Dumazet authored
      commit dc808110 upstream.
      
      af_packet can currently overwrite kernel memory by out of bound
      accesses, because it assumed a [new] block can always hold one frame.
      
      This is not generally the case, even if most existing tools do it right.
      
      This patch clamps too long frames as API permits, and issue a one time
      error on syslog.
      
      [  394.357639] tpacket_rcv: packet too big, clamped from 5042 to 3966. macoff=82
      
      In this example, packet header tp_snaplen was set to 3966,
      and tp_len was set to 5042 (skb->len)
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7a57c268