1. 23 Nov, 2018 1 commit
    • Xin Long's avatar
      sctp: not allow to set asoc prsctp_enable by sockopt · c7051eb3
      Xin Long authored
      [ Upstream commit cc3ccf26f0649089b3a34a2781977755ea36e72c ]
      
      As rfc7496#section4.5 says about SCTP_PR_SUPPORTED:
      
         This socket option allows the enabling or disabling of the
         negotiation of PR-SCTP support for future associations.  For existing
         associations, it allows one to query whether or not PR-SCTP support
         was negotiated on a particular association.
      
      It means only sctp sock's prsctp_enable can be set.
      
      Note that for the limitation of SCTP_{CURRENT|ALL}_ASSOC, we will
      add it when introducing SCTP_{FUTURE|CURRENT|ALL}_ASSOC for linux
      sctp in another patchset.
      
      v1->v2:
        - drop the params.assoc_id check as Neil suggested.
      
      Fixes: 28aa4c26 ("sctp: add SCTP_PR_SUPPORTED on sctp sockopt")
      Reported-by: 's avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7051eb3
  2. 04 Nov, 2018 1 commit
    • Marcelo Ricardo Leitner's avatar
      sctp: fix race on sctp_id2asoc · 606694e5
      Marcelo Ricardo Leitner authored
      [ Upstream commit b336deca ]
      
      syzbot reported an use-after-free involving sctp_id2asoc.  Dmitry Vyukov
      helped to root cause it and it is because of reading the asoc after it
      was freed:
      
              CPU 1                       CPU 2
      (working on socket 1)            (working on socket 2)
      	                         sctp_association_destroy
      sctp_id2asoc
         spin lock
           grab the asoc from idr
         spin unlock
                                         spin lock
      				     remove asoc from idr
      				   spin unlock
      				   free(asoc)
         if asoc->base.sk != sk ... [*]
      
      This can only be hit if trying to fetch asocs from different sockets. As
      we have a single IDR for all asocs, in all SCTP sockets, their id is
      unique on the system. An application can try to send stuff on an id
      that matches on another socket, and the if in [*] will protect from such
      usage. But it didn't consider that as that asoc may belong to another
      socket, it may be freed in parallel (read: under another socket lock).
      
      We fix it by moving the checks in [*] into the protected region. This
      fixes it because the asoc cannot be freed while the lock is held.
      
      Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
      Acked-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      606694e5
  3. 15 Sep, 2018 1 commit
  4. 12 Apr, 2018 1 commit
    • Eric Dumazet's avatar
      sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6 · 3fdd4370
      Eric Dumazet authored
      
      [ Upstream commit 81e98370 ]
      
      Check must happen before call to ipv6_addr_v4mapped()
      
      syzbot report was :
      
      BUG: KMSAN: uninit-value in sctp_sockaddr_af net/sctp/socket.c:359 [inline]
      BUG: KMSAN: uninit-value in sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
      CPU: 0 PID: 3576 Comm: syzkaller968804 Not tainted 4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
       sctp_sockaddr_af net/sctp/socket.c:359 [inline]
       sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
       sctp_bind+0x149/0x190 net/sctp/socket.c:332
       inet6_bind+0x1fd/0x1820 net/ipv6/af_inet6.c:293
       SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
       SyS_bind+0x54/0x80 net/socket.c:1460
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43fd49
      RSP: 002b:00007ffe99df3d28 EFLAGS: 00000213 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
      RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
      R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----address@SYSC_bind
      Variable was created at:
       SYSC_bind+0x6f/0x4b0 net/socket.c:1461
       SyS_bind+0x54/0x80 net/socket.c:1460
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fdd4370
  5. 03 Mar, 2018 2 commits
  6. 25 Feb, 2018 1 commit
  7. 31 Jan, 2018 3 commits
  8. 02 Jan, 2018 2 commits
  9. 17 Dec, 2017 1 commit
  10. 14 Dec, 2017 2 commits
  11. 29 Oct, 2017 1 commit
    • Xin Long's avatar
      sctp: reset owner sk for data chunks on out queues when migrating a sock · d04adf1b
      Xin Long authored
      Now when migrating sock to another one in sctp_sock_migrate(), it only
      resets owner sk for the data in receive queues, not the chunks on out
      queues.
      
      It would cause that data chunks length on the sock is not consistent
      with sk sk_wmem_alloc. When closing the sock or freeing these chunks,
      the old sk would never be freed, and the new sock may crash due to
      the overflow sk_wmem_alloc.
      
      syzbot found this issue with this series:
      
        r0 = socket$inet_sctp()
        sendto$inet(r0)
        listen(r0)
        accept4(r0)
        close(r0)
      
      Although listen() should have returned error when one TCP-style socket
      is in connecting (I may fix this one in another patch), it could also
      be reproduced by peeling off an assoc.
      
      This issue is there since very beginning.
      
      This patch is to reset owner sk for the chunks on out queues so that
      sk sk_wmem_alloc has correct value after accept one sock or peeloff
      an assoc to one sock.
      
      Note that when resetting owner sk for chunks on outqueue, it has to
      sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk
      first and then sctp_set_owner_w them after changing assoc->base.sk,
      due to that sctp_wfree and it's callees are using assoc->base.sk.
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      d04adf1b
  12. 19 Oct, 2017 1 commit
    • Xin Long's avatar
      sctp: do not peel off an assoc from one netns to another one · df80cd9b
      Xin Long authored
      Now when peeling off an association to the sock in another netns, all
      transports in this assoc are not to be rehashed and keep use the old
      key in hashtable.
      
      As a transport uses sk->net as the hash key to insert into hashtable,
      it would miss removing these transports from hashtable due to the new
      netns when closing the sock and all transports are being freeed, then
      later an use-after-free issue could be caused when looking up an asoc
      and dereferencing those transports.
      
      This is a very old issue since very beginning, ChunYu found it with
      syzkaller fuzz testing with this series:
      
        socket$inet6_sctp()
        bind$inet6()
        sendto$inet6()
        unshare(0x40000000)
        getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
        getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
      
      This patch is to block this call when peeling one assoc off from one
      netns to another one, so that the netns of all transport would not
      go out-sync with the key in hashtable.
      
      Note that this patch didn't fix it by rehashing transports, as it's
      difficult to handle the situation when the tuple is already in use
      in the new netns. Besides, no one would like to peel off one assoc
      to another netns, considering ipaddrs, ifaces, etc. are usually
      different.
      Reported-by: 's avatarChunYu Wang <chunwang@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      df80cd9b
  13. 15 Sep, 2017 1 commit
    • Xin Long's avatar
      sctp: fix an use-after-free issue in sctp_sock_dump · d25adbeb
      Xin Long authored
      Commit 86fdb344 ("sctp: ensure ep is not destroyed before doing the
      dump") tried to fix an use-after-free issue by checking !sctp_sk(sk)->ep
      with holding sock and sock lock.
      
      But Paolo noticed that endpoint could be destroyed in sctp_rcv without
      sock lock protection. It means the use-after-free issue still could be
      triggered when sctp_rcv put and destroy ep after sctp_sock_dump checks
      !ep, although it's pretty hard to reproduce.
      
      I could reproduce it by mdelay in sctp_rcv while msleep in sctp_close
      and sctp_sock_dump long time.
      
      This patch is to add another param cb_done to sctp_for_each_transport
      and dump ep->assocs with holding tsp after jumping out of transport's
      traversal in it to avoid this issue.
      
      It can also improve sctp diag dump to make it run faster, as no need
      to save sk into cb->args[5] and keep calling sctp_for_each_transport
      any more.
      
      This patch is also to use int * instead of int for the pos argument
      in sctp_for_each_transport, which could make postion increment only
      in sctp_for_each_transport and no need to keep changing cb->args[2]
      in sctp_sock_filter and sctp_sock_dump any more.
      
      Fixes: 86fdb344 ("sctp: ensure ep is not destroyed before doing the dump")
      Reported-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      d25adbeb
  14. 24 Aug, 2017 1 commit
    • Stefano Brivio's avatar
      sctp: Avoid out-of-bounds reads from address storage · ee6c88bb
      Stefano Brivio authored
      inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy
      sizeof(sockaddr_storage) bytes to fill in sockaddr structs used
      to export diagnostic information to userspace.
      
      However, the memory allocated to store sockaddr information is
      smaller than that and depends on the address family, so we leak
      up to 100 uninitialized bytes to userspace. Just use the size of
      the source structs instead, in all the three cases this is what
      userspace expects. Zero out the remaining memory.
      
      Unused bytes (i.e. when IPv4 addresses are used) in source
      structs sctp_sockaddr_entry and sctp_transport are already
      cleared by sctp_add_bind_addr() and sctp_transport_new(),
      respectively.
      
      Noticed while testing KASAN-enabled kernel with 'ss':
      
      [ 2326.885243] BUG: KASAN: slab-out-of-bounds in inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag] at addr ffff881be8779800
      [ 2326.896800] Read of size 128 by task ss/9527
      [ 2326.901564] CPU: 0 PID: 9527 Comm: ss Not tainted 4.11.0-22.el7a.x86_64 #1
      [ 2326.909236] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
      [ 2326.917585] Call Trace:
      [ 2326.920312]  dump_stack+0x63/0x8d
      [ 2326.924014]  kasan_object_err+0x21/0x70
      [ 2326.928295]  kasan_report+0x288/0x540
      [ 2326.932380]  ? inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag]
      [ 2326.938500]  ? skb_put+0x8b/0xd0
      [ 2326.942098]  ? memset+0x31/0x40
      [ 2326.945599]  check_memory_region+0x13c/0x1a0
      [ 2326.950362]  memcpy+0x23/0x50
      [ 2326.953669]  inet_sctp_diag_fill+0x42c/0x6c0 [sctp_diag]
      [ 2326.959596]  ? inet_diag_msg_sctpasoc_fill+0x460/0x460 [sctp_diag]
      [ 2326.966495]  ? __lock_sock+0x102/0x150
      [ 2326.970671]  ? sock_def_wakeup+0x60/0x60
      [ 2326.975048]  ? remove_wait_queue+0xc0/0xc0
      [ 2326.979619]  sctp_diag_dump+0x44a/0x760 [sctp_diag]
      [ 2326.985063]  ? sctp_ep_dump+0x280/0x280 [sctp_diag]
      [ 2326.990504]  ? memset+0x31/0x40
      [ 2326.994007]  ? mutex_lock+0x12/0x40
      [ 2326.997900]  __inet_diag_dump+0x57/0xb0 [inet_diag]
      [ 2327.003340]  ? __sys_sendmsg+0x150/0x150
      [ 2327.007715]  inet_diag_dump+0x4d/0x80 [inet_diag]
      [ 2327.012979]  netlink_dump+0x1e6/0x490
      [ 2327.017064]  __netlink_dump_start+0x28e/0x2c0
      [ 2327.021924]  inet_diag_handler_cmd+0x189/0x1a0 [inet_diag]
      [ 2327.028045]  ? inet_diag_rcv_msg_compat+0x1b0/0x1b0 [inet_diag]
      [ 2327.034651]  ? inet_diag_dump_compat+0x190/0x190 [inet_diag]
      [ 2327.040965]  ? __netlink_lookup+0x1b9/0x260
      [ 2327.045631]  sock_diag_rcv_msg+0x18b/0x1e0
      [ 2327.050199]  netlink_rcv_skb+0x14b/0x180
      [ 2327.054574]  ? sock_diag_bind+0x60/0x60
      [ 2327.058850]  sock_diag_rcv+0x28/0x40
      [ 2327.062837]  netlink_unicast+0x2e7/0x3b0
      [ 2327.067212]  ? netlink_attachskb+0x330/0x330
      [ 2327.071975]  ? kasan_check_write+0x14/0x20
      [ 2327.076544]  netlink_sendmsg+0x5be/0x730
      [ 2327.080918]  ? netlink_unicast+0x3b0/0x3b0
      [ 2327.085486]  ? kasan_check_write+0x14/0x20
      [ 2327.090057]  ? selinux_socket_sendmsg+0x24/0x30
      [ 2327.095109]  ? netlink_unicast+0x3b0/0x3b0
      [ 2327.099678]  sock_sendmsg+0x74/0x80
      [ 2327.103567]  ___sys_sendmsg+0x520/0x530
      [ 2327.107844]  ? __get_locked_pte+0x178/0x200
      [ 2327.112510]  ? copy_msghdr_from_user+0x270/0x270
      [ 2327.117660]  ? vm_insert_page+0x360/0x360
      [ 2327.122133]  ? vm_insert_pfn_prot+0xb4/0x150
      [ 2327.126895]  ? vm_insert_pfn+0x32/0x40
      [ 2327.131077]  ? vvar_fault+0x71/0xd0
      [ 2327.134968]  ? special_mapping_fault+0x69/0x110
      [ 2327.140022]  ? __do_fault+0x42/0x120
      [ 2327.144008]  ? __handle_mm_fault+0x1062/0x17a0
      [ 2327.148965]  ? __fget_light+0xa7/0xc0
      [ 2327.153049]  __sys_sendmsg+0xcb/0x150
      [ 2327.157133]  ? __sys_sendmsg+0xcb/0x150
      [ 2327.161409]  ? SyS_shutdown+0x140/0x140
      [ 2327.165688]  ? exit_to_usermode_loop+0xd0/0xd0
      [ 2327.170646]  ? __do_page_fault+0x55d/0x620
      [ 2327.175216]  ? __sys_sendmsg+0x150/0x150
      [ 2327.179591]  SyS_sendmsg+0x12/0x20
      [ 2327.183384]  do_syscall_64+0xe3/0x230
      [ 2327.187471]  entry_SYSCALL64_slow_path+0x25/0x25
      [ 2327.192622] RIP: 0033:0x7f41d18fa3b0
      [ 2327.196608] RSP: 002b:00007ffc3b731218 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [ 2327.205055] RAX: ffffffffffffffda RBX: 00007ffc3b731380 RCX: 00007f41d18fa3b0
      [ 2327.213017] RDX: 0000000000000000 RSI: 00007ffc3b731340 RDI: 0000000000000003
      [ 2327.220978] RBP: 0000000000000002 R08: 0000000000000004 R09: 0000000000000040
      [ 2327.228939] R10: 00007ffc3b730f30 R11: 0000000000000246 R12: 0000000000000003
      [ 2327.236901] R13: 00007ffc3b731340 R14: 00007ffc3b7313d0 R15: 0000000000000084
      [ 2327.244865] Object at ffff881be87797e0, in cache kmalloc-64 size: 64
      [ 2327.251953] Allocated:
      [ 2327.254581] PID = 9484
      [ 2327.257215]  save_stack_trace+0x1b/0x20
      [ 2327.261485]  save_stack+0x46/0xd0
      [ 2327.265179]  kasan_kmalloc+0xad/0xe0
      [ 2327.269165]  kmem_cache_alloc_trace+0xe6/0x1d0
      [ 2327.274138]  sctp_add_bind_addr+0x58/0x180 [sctp]
      [ 2327.279400]  sctp_do_bind+0x208/0x310 [sctp]
      [ 2327.284176]  sctp_bind+0x61/0xa0 [sctp]
      [ 2327.288455]  inet_bind+0x5f/0x3a0
      [ 2327.292151]  SYSC_bind+0x1a4/0x1e0
      [ 2327.295944]  SyS_bind+0xe/0x10
      [ 2327.299349]  do_syscall_64+0xe3/0x230
      [ 2327.303433]  return_from_SYSCALL_64+0x0/0x6a
      [ 2327.308194] Freed:
      [ 2327.310434] PID = 4131
      [ 2327.313065]  save_stack_trace+0x1b/0x20
      [ 2327.317344]  save_stack+0x46/0xd0
      [ 2327.321040]  kasan_slab_free+0x73/0xc0
      [ 2327.325220]  kfree+0x96/0x1a0
      [ 2327.328530]  dynamic_kobj_release+0x15/0x40
      [ 2327.333195]  kobject_release+0x99/0x1e0
      [ 2327.337472]  kobject_put+0x38/0x70
      [ 2327.341266]  free_notes_attrs+0x66/0x80
      [ 2327.345545]  mod_sysfs_teardown+0x1a5/0x270
      [ 2327.350211]  free_module+0x20/0x2a0
      [ 2327.354099]  SyS_delete_module+0x2cb/0x2f0
      [ 2327.358667]  do_syscall_64+0xe3/0x230
      [ 2327.362750]  return_from_SYSCALL_64+0x0/0x6a
      [ 2327.367510] Memory state around the buggy address:
      [ 2327.372855]  ffff881be8779700: fc fc fc fc 00 00 00 00 00 00 00 00 fc fc fc fc
      [ 2327.380914]  ffff881be8779780: fb fb fb fb fb fb fb fb fc fc fc fc 00 00 00 00
      [ 2327.388972] >ffff881be8779800: 00 00 00 00 fc fc fc fc fb fb fb fb fb fb fb fb
      [ 2327.397031]                                ^
      [ 2327.401792]  ffff881be8779880: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
      [ 2327.409850]  ffff881be8779900: 00 00 00 00 00 04 fc fc fc fc fc fc 00 00 00 00
      [ 2327.417907] ==================================================================
      
      This fixes CVE-2017-7558.
      
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1480266
      Fixes: 8f840e47 ("sctp: add the sctp_diag.c file")
      Cc: Xin Long <lucien.xin@gmail.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarStefano Brivio <sbrivio@redhat.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reviewed-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      ee6c88bb
  15. 11 Aug, 2017 2 commits
  16. 07 Aug, 2017 1 commit
  17. 01 Jul, 2017 4 commits
  18. 15 Jun, 2017 1 commit
    • Xin Long's avatar
      sctp: return next obj by passing pos + 1 into sctp_transport_get_idx · 988c7322
      Xin Long authored
      In sctp_for_each_transport, pos is used to save how many objs it has
      dumped. Now it gets the last obj by sctp_transport_get_idx, then gets
      the next obj by sctp_transport_get_next.
      
      The issue is that in the meanwhile if some objs in transport hashtable
      are removed and the objs nums are less than pos, sctp_transport_get_idx
      would return NULL and hti.walker.tbl is NULL as well. At this moment
      it should stop hti, instead of continue getting the next obj. Or it
      would cause a NULL pointer dereference in sctp_transport_get_next.
      
      This patch is to pass pos + 1 into sctp_transport_get_idx to get the
      next obj directly, even if pos > objs nums, it would return NULL and
      stop hti.
      
      Fixes: 626d16f5 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      988c7322
  19. 10 Jun, 2017 2 commits
    • Xin Long's avatar
      sctp: fix recursive locking warning in sctp_do_peeloff · 6dfe4b97
      Xin Long authored
      Dmitry got the following recursive locking report while running syzkaller
      fuzzer, the Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
       print_deadlock_bug kernel/locking/lockdep.c:1729 [inline]
       check_deadlock kernel/locking/lockdep.c:1773 [inline]
       validate_chain kernel/locking/lockdep.c:2251 [inline]
       __lock_acquire+0xef2/0x3430 kernel/locking/lockdep.c:3340
       lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
       lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
       lock_sock include/net/sock.h:1460 [inline]
       sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
       sock_release+0x8d/0x1e0 net/socket.c:597
       __sock_create+0x38b/0x870 net/socket.c:1226
       sock_create+0x7f/0xa0 net/socket.c:1237
       sctp_do_peeloff+0x1a2/0x440 net/sctp/socket.c:4879
       sctp_getsockopt_peeloff net/sctp/socket.c:4914 [inline]
       sctp_getsockopt+0x111a/0x67e0 net/sctp/socket.c:6628
       sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2690
       SYSC_getsockopt net/socket.c:1817 [inline]
       SyS_getsockopt+0x240/0x380 net/socket.c:1799
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      This warning is caused by the lock held by sctp_getsockopt() is on one
      socket, while the other lock that sctp_close() is getting later is on
      the newly created (which failed) socket during peeloff operation.
      
      This patch is to avoid this warning by use lock_sock with subclass
      SINGLE_DEPTH_NESTING as Wang Cong and Marcelo's suggestion.
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Suggested-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Suggested-by: 's avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      6dfe4b97
    • Xin Long's avatar
      sctp: disable BH in sctp_for_each_endpoint · 581409da
      Xin Long authored
      Now sctp holds read_lock when foreach sctp_ep_hashtable without disabling
      BH. If CPU schedules to another thread A at this moment, the thread A may
      be trying to hold the write_lock with disabling BH.
      
      As BH is disabled and CPU cannot schedule back to the thread holding the
      read_lock, while the thread A keeps waiting for the read_lock. A dead
      lock would be triggered by this.
      
      This patch is to fix this dead lock by calling read_lock_bh instead to
      disable BH when holding the read_lock in sctp_for_each_endpoint.
      
      Fixes: 626d16f5 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
      Reported-by: 's avatarXiumei Mu <xmu@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      581409da
  20. 08 Jun, 2017 1 commit
    • Eric Dumazet's avatar
      tcp: add TCPMemoryPressuresChrono counter · 06044751
      Eric Dumazet authored
      DRAM supply shortage and poor memory pressure tracking in TCP
      stack makes any change in SO_SNDBUF/SO_RCVBUF (or equivalent autotuning
      limits) and tcp_mem[] quite hazardous.
      
      TCPMemoryPressures SNMP counter is an indication of tcp_mem sysctl
      limits being hit, but only tracking number of transitions.
      
      If TCP stack behavior under stress was perfect :
      1) It would maintain memory usage close to the limit.
      2) Memory pressure state would be entered for short times.
      
      We certainly prefer 100 events lasting 10ms compared to one event
      lasting 200 seconds.
      
      This patch adds a new SNMP counter tracking cumulative duration of
      memory pressure events, given in ms units.
      
      $ cat /proc/sys/net/ipv4/tcp_mem
      3088    4117    6176
      $ grep TCP /proc/net/sockstat
      TCP: inuse 180 orphan 0 tw 2 alloc 234 mem 4140
      $ nstat -n ; sleep 10 ; nstat |grep Pressure
      TcpExtTCPMemoryPressures        1700
      TcpExtTCPMemoryPressuresChrono  5209
      
      v2: Used EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() as David
      instructed.
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      06044751
  21. 02 Jun, 2017 1 commit
  22. 06 Apr, 2017 1 commit
  23. 05 Apr, 2017 1 commit
  24. 03 Apr, 2017 1 commit
  25. 02 Apr, 2017 1 commit
  26. 29 Mar, 2017 1 commit
    • Xin Long's avatar
      sctp: change to save MSG_MORE flag into assoc · f9ba3501
      Xin Long authored
      David Laight noticed the support for MSG_MORE with datamsg->force_delay
      didn't really work as we expected, as the first msg with MSG_MORE set
      would always block the following chunks' dequeuing.
      
      This Patch is to rewrite it by saving the MSG_MORE flag into assoc as
      David Laight suggested.
      
      asoc->force_delay is used to save MSG_MORE flag before a msg is sent.
      All chunks in queue would not be sent out if asoc->force_delay is set
      by the msg with MSG_MORE flag, until a new msg without MSG_MORE flag
      clears asoc->force_delay.
      
      Note that this change would not affect the flush is generated by other
      triggers, like asoc->state != ESTABLISHED, queue size > pmtu etc.
      
      v1->v2:
        Not clear asoc->force_delay after sending the msg with MSG_MORE flag.
      
      Fixes: 4ea0c32f ("sctp: add support for MSG_MORE")
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarDavid Laight <david.laight@aculab.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      f9ba3501
  27. 25 Mar, 2017 1 commit
  28. 13 Mar, 2017 1 commit
  29. 10 Mar, 2017 1 commit
    • David Howells's avatar
      net: Work around lockdep limitation in sockets that use sockets · cdfbabfb
      David Howells authored
      Lockdep issues a circular dependency warning when AFS issues an operation
      through AF_RXRPC from a context in which the VFS/VM holds the mmap_sem.
      
      The theory lockdep comes up with is as follows:
      
       (1) If the pagefault handler decides it needs to read pages from AFS, it
           calls AFS with mmap_sem held and AFS begins an AF_RXRPC call, but
           creating a call requires the socket lock:
      
      	mmap_sem must be taken before sk_lock-AF_RXRPC
      
       (2) afs_open_socket() opens an AF_RXRPC socket and binds it.  rxrpc_bind()
           binds the underlying UDP socket whilst holding its socket lock.
           inet_bind() takes its own socket lock:
      
      	sk_lock-AF_RXRPC must be taken before sk_lock-AF_INET
      
       (3) Reading from a TCP socket into a userspace buffer might cause a fault
           and thus cause the kernel to take the mmap_sem, but the TCP socket is
           locked whilst doing this:
      
      	sk_lock-AF_INET must be taken before mmap_sem
      
      However, lockdep's theory is wrong in this instance because it deals only
      with lock classes and not individual locks.  The AF_INET lock in (2) isn't
      really equivalent to the AF_INET lock in (3) as the former deals with a
      socket entirely internal to the kernel that never sees userspace.  This is
      a limitation in the design of lockdep.
      
      Fix the general case by:
      
       (1) Double up all the locking keys used in sockets so that one set are
           used if the socket is created by userspace and the other set is used
           if the socket is created by the kernel.
      
       (2) Store the kern parameter passed to sk_alloc() in a variable in the
           sock struct (sk_kern_sock).  This informs sock_lock_init(),
           sock_init_data() and sk_clone_lock() as to the lock keys to be used.
      
           Note that the child created by sk_clone_lock() inherits the parent's
           kern setting.
      
       (3) Add a 'kern' parameter to ->accept() that is analogous to the one
           passed in to ->create() that distinguishes whether kernel_accept() or
           sys_accept4() was the caller and can be passed to sk_alloc().
      
           Note that a lot of accept functions merely dequeue an already
           allocated socket.  I haven't touched these as the new socket already
           exists before we get the parameter.
      
           Note also that there are a couple of places where I've made the accepted
           socket unconditionally kernel-based:
      
      	irda_accept()
      	rds_rcp_accept_one()
      	tcp_accept_from_sock()
      
           because they follow a sock_create_kern() and accept off of that.
      
      Whilst creating this, I noticed that lustre and ocfs don't create sockets
      through sock_create_kern() and thus they aren't marked as for-kernel,
      though they appear to be internal.  I wonder if these should do that so
      that they use the new set of lock keys.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      cdfbabfb
  30. 02 Mar, 2017 1 commit