1. 03 Jul, 2019 1 commit
  2. 22 Jun, 2019 1 commit
    • Neil Horman's avatar
      sctp: Free cookie before we memdup a new one · c4964bfa
      Neil Horman authored
      [ Upstream commit ce950f1050cece5e406a5cde723c69bba60e1b26 ]
      
      Based on comments from Xin, even after fixes for our recent syzbot
      report of cookie memory leaks, its possible to get a resend of an INIT
      chunk which would lead to us leaking cookie memory.
      
      To ensure that we don't leak cookie memory, free any previously
      allocated cookie first.
      
      Change notes
      v1->v2
      update subsystem tag in subject (davem)
      repeat kfree check for peer_random and peer_hmacs (xin)
      
      v2->v3
      net->sctp
      also free peer_chunks
      
      v3->v4
      fix subject tags
      
      v4->v5
      remove cut line
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: Xin Long <lucien.xin@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4964bfa
  3. 11 Jun, 2019 1 commit
    • Neil Horman's avatar
      Fix memory leak in sctp_process_init · 2cdb66cc
      Neil Horman authored
      [ Upstream commit 0a8dd9f67cd0da7dc284f48b032ce00db1a68791 ]
      
      syzbot found the following leak in sctp_process_init
      BUG: memory leak
      unreferenced object 0xffff88810ef68400 (size 1024):
        comm "syz-executor273", pid 7046, jiffies 4294945598 (age 28.770s)
        hex dump (first 32 bytes):
          1d de 28 8d de 0b 1b e3 b5 c2 f9 68 fd 1a 97 25  ..(........h...%
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000a02cebbd>] kmemleak_alloc_recursive include/linux/kmemleak.h:55
      [inline]
          [<00000000a02cebbd>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000a02cebbd>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000a02cebbd>] __do_kmalloc mm/slab.c:3658 [inline]
          [<00000000a02cebbd>] __kmalloc_track_caller+0x15d/0x2c0 mm/slab.c:3675
          [<000000009e6245e6>] kmemdup+0x27/0x60 mm/util.c:119
          [<00000000dfdc5d2d>] kmemdup include/linux/string.h:432 [inline]
          [<00000000dfdc5d2d>] sctp_process_init+0xa7e/0xc20
      net/sctp/sm_make_chunk.c:2437
          [<00000000b58b62f8>] sctp_cmd_process_init net/sctp/sm_sideeffect.c:682
      [inline]
          [<00000000b58b62f8>] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1384
      [inline]
          [<00000000b58b62f8>] sctp_side_effects net/sctp/sm_sideeffect.c:1194
      [inline]
          [<00000000b58b62f8>] sctp_do_sm+0xbdc/0x1d60 net/sctp/sm_sideeffect.c:1165
          [<0000000044e11f96>] sctp_assoc_bh_rcv+0x13c/0x200
      net/sctp/associola.c:1074
          [<00000000ec43804d>] sctp_inq_push+0x7f/0xb0 net/sctp/inqueue.c:95
          [<00000000726aa954>] sctp_backlog_rcv+0x5e/0x2a0 net/sctp/input.c:354
          [<00000000d9e249a8>] sk_backlog_rcv include/net/sock.h:950 [inline]
          [<00000000d9e249a8>] __release_sock+0xab/0x110 net/core/sock.c:2418
          [<00000000acae44fa>] release_sock+0x37/0xd0 net/core/sock.c:2934
          [<00000000963cc9ae>] sctp_sendmsg+0x2c0/0x990 net/sctp/socket.c:2122
          [<00000000a7fc7565>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
          [<00000000b732cbd3>] sock_sendmsg_nosec net/socket.c:652 [inline]
          [<00000000b732cbd3>] sock_sendmsg+0x54/0x70 net/socket.c:671
          [<00000000274c57ab>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2292
          [<000000008252aedb>] __sys_sendmsg+0x80/0xf0 net/socket.c:2330
          [<00000000f7bf23d1>] __do_sys_sendmsg net/socket.c:2339 [inline]
          [<00000000f7bf23d1>] __se_sys_sendmsg net/socket.c:2337 [inline]
          [<00000000f7bf23d1>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2337
          [<00000000a8b4131f>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:3
      
      The problem was that the peer.cookie value points to an skb allocated
      area on the first pass through this function, at which point it is
      overwritten with a heap allocated value, but in certain cases, where a
      COOKIE_ECHO chunk is included in the packet, a second pass through
      sctp_process_init is made, where the cookie value is re-allocated,
      leaking the first allocation.
      
      Fix is to always allocate the cookie value, and free it when we are done
      using it.
      Signed-off-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cdb66cc
  4. 08 May, 2019 1 commit
    • Xin Long's avatar
      sctp: avoid running the sctp state machine recursively · a5d00345
      Xin Long authored
      [ Upstream commit fbd019737d71e405f86549fd738f81e2ff3dd073 ]
      
      Ying triggered a call trace when doing an asconf testing:
      
        BUG: scheduling while atomic: swapper/12/0/0x10000100
        Call Trace:
         <IRQ>  [<ffffffffa4375904>] dump_stack+0x19/0x1b
         [<ffffffffa436fcaf>] __schedule_bug+0x64/0x72
         [<ffffffffa437b93a>] __schedule+0x9ba/0xa00
         [<ffffffffa3cd5326>] __cond_resched+0x26/0x30
         [<ffffffffa437bc4a>] _cond_resched+0x3a/0x50
         [<ffffffffa3e22be8>] kmem_cache_alloc_node+0x38/0x200
         [<ffffffffa423512d>] __alloc_skb+0x5d/0x2d0
         [<ffffffffc0995320>] sctp_packet_transmit+0x610/0xa20 [sctp]
         [<ffffffffc098510e>] sctp_outq_flush+0x2ce/0xc00 [sctp]
         [<ffffffffc098646c>] sctp_outq_uncork+0x1c/0x20 [sctp]
         [<ffffffffc0977338>] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp]
         [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
         [<ffffffffc099443d>] sctp_primitive_ASCONF+0x3d/0x50 [sctp]
         [<ffffffffc0977384>] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp]
         [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
         [<ffffffffc097b3a4>] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp]
         [<ffffffffc09840f1>] sctp_inq_push+0x51/0x70 [sctp]
         [<ffffffffc099732b>] sctp_rcv+0xa8b/0xbd0 [sctp]
      
      As it shows, the first sctp_do_sm() running under atomic context (NET_RX
      softirq) invoked sctp_primitive_ASCONF() that uses GFP_KERNEL flag later,
      and this flag is supposed to be used in non-atomic context only. Besides,
      sctp_do_sm() was called recursively, which is not expected.
      
      Vlad tried to fix this recursive call in Commit c0786693 ("sctp: Fix
      oops when sending queued ASCONF chunks") by introducing a new command
      SCTP_CMD_SEND_NEXT_ASCONF. But it didn't work as this command is still
      used in the first sctp_do_sm() call, and sctp_primitive_ASCONF() will
      be called in this command again.
      
      To avoid calling sctp_do_sm() recursively, we send the next queued ASCONF
      not by sctp_primitive_ASCONF(), but by sctp_sf_do_prm_asconf() in the 1st
      sctp_do_sm() directly.
      Reported-by: 's avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5d00345
  5. 17 Apr, 2019 1 commit
    • Xin Long's avatar
      sctp: initialize _pad of sockaddr_in before copying to user memory · a7bc830b
      Xin Long authored
      [ Upstream commit 09279e615c81ce55e04835970601ae286e3facbe ]
      
      Syzbot report a kernel-infoleak:
      
        BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
        Call Trace:
          _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
          copy_to_user include/linux/uaccess.h:174 [inline]
          sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
          sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
          ...
        Uninit was stored to memory at:
          sctp_transport_init net/sctp/transport.c:61 [inline]
          sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
          sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
          sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
          sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
          ...
        Bytes 8-15 of 16 are uninitialized
      
      It was caused by that th _pad field (the 8-15 bytes) of a v4 addr (saved in
      struct sockaddr_in) wasn't initialized, but directly copied to user memory
      in sctp_getsockopt_peer_addrs().
      
      So fix it by calling memset(addr->v4.sin_zero, 0, 8) to initialize _pad of
      sockaddr_in before copying it to user memory in sctp_v4_addr_to_user(), as
      sctp_v6_addr_to_user() does.
      
      Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Tested-by: 's avatarAlexander Potapenko <glider@google.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>
      a7bc830b
  6. 27 Feb, 2019 2 commits
    • Konstantin Khlebnikov's avatar
      inet_diag: fix reporting cgroup classid and fallback to priority · 3daca16b
      Konstantin Khlebnikov authored
      [ Upstream commit 1ec17dbd90f8b638f41ee650558609c1af63dfa0 ]
      
      Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
      extensions has only 8 bits. Thus extensions starting from DCTCPINFO
      cannot be requested directly. Some of them included into response
      unconditionally or hook into some of lower 8 bits.
      
      Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
      
      This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
      reservation, and documents behavior for other extensions.
      
      Also this patch adds fallback to reporting socket priority. This filed
      is more widely used for traffic classification because ipv4 sockets
      automatically maps TOS to priority and default qdisc pfifo_fast knows
      about that. But priority could be changed via setsockopt SO_PRIORITY so
      INET_DIAG_TOS isn't enough for predicting class.
      
      Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
      reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
      
      So, after this patch INET_DIAG_CLASS_ID will report socket priority
      for most common setup when net_cls isn't set and/or cgroup2 in use.
      
      Fixes: 0888e372 ("net: inet: diag: expose sockets cgroup classid")
      Signed-off-by: 's avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3daca16b
    • Xin Long's avatar
      sctp: call gso_reset_checksum when computing checksum in sctp_gso_segment · 77278f05
      Xin Long authored
      [ Upstream commit fc228abc2347e106a44c0e9b29ab70b712c4ca51 ]
      
      Jianlin reported a panic when running sctp gso over gre over vlan device:
      
        [   84.772930] RIP: 0010:do_csum+0x6d/0x170
        [   84.790605] Call Trace:
        [   84.791054]  csum_partial+0xd/0x20
        [   84.791657]  gre_gso_segment+0x2c3/0x390
        [   84.792364]  inet_gso_segment+0x161/0x3e0
        [   84.793071]  skb_mac_gso_segment+0xb8/0x120
        [   84.793846]  __skb_gso_segment+0x7e/0x180
        [   84.794581]  validate_xmit_skb+0x141/0x2e0
        [   84.795297]  __dev_queue_xmit+0x258/0x8f0
        [   84.795949]  ? eth_header+0x26/0xc0
        [   84.796581]  ip_finish_output2+0x196/0x430
        [   84.797295]  ? skb_gso_validate_network_len+0x11/0x80
        [   84.798183]  ? ip_finish_output+0x169/0x270
        [   84.798875]  ip_output+0x6c/0xe0
        [   84.799413]  ? ip_append_data.part.50+0xc0/0xc0
        [   84.800145]  iptunnel_xmit+0x144/0x1c0
        [   84.800814]  ip_tunnel_xmit+0x62d/0x930 [ip_tunnel]
        [   84.801699]  gre_tap_xmit+0xac/0xf0 [ip_gre]
        [   84.802395]  dev_hard_start_xmit+0xa5/0x210
        [   84.803086]  sch_direct_xmit+0x14f/0x340
        [   84.803733]  __dev_queue_xmit+0x799/0x8f0
        [   84.804472]  ip_finish_output2+0x2e0/0x430
        [   84.805255]  ? skb_gso_validate_network_len+0x11/0x80
        [   84.806154]  ip_output+0x6c/0xe0
        [   84.806721]  ? ip_append_data.part.50+0xc0/0xc0
        [   84.807516]  sctp_packet_transmit+0x716/0xa10 [sctp]
        [   84.808337]  sctp_outq_flush+0xd7/0x880 [sctp]
      
      It was caused by SKB_GSO_CB(skb)->csum_start not set in sctp_gso_segment.
      sctp_gso_segment() calls skb_segment() with 'feature | NETIF_F_HW_CSUM',
      which causes SKB_GSO_CB(skb)->csum_start not to be set in skb_segment().
      
      For TCP/UDP, when feature supports HW_CSUM, CHECKSUM_PARTIAL will be set
      and gso_reset_checksum will be called to set SKB_GSO_CB(skb)->csum_start.
      
      So SCTP should do the same as TCP/UDP, to call gso_reset_checksum() when
      computing checksum in sctp_gso_segment.
      Reported-by: 's avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77278f05
  7. 06 Feb, 2019 2 commits
    • Xin Long's avatar
      sctp: improve the events for sctp stream reset · 556e554a
      Xin Long authored
      [ Upstream commit 2e6dc4d95110becfe0ff4c3d4749c33ea166e9e7 ]
      
      This patch is to improve sctp stream reset events in 4 places:
      
        1. In sctp_process_strreset_outreq(), the flag should always be set with
           SCTP_STREAM_RESET_INCOMING_SSN instead of OUTGOING, as receiver's in
           stream is reset here.
        2. In sctp_process_strreset_outreq(), move up SCTP_STRRESET_ERR_WRONG_SSN
           check, as the reset has to succeed after reconf_timer stops for the
           in stream reset request retransmission.
        3. In sctp_process_strreset_inreq(), no event should be sent, as no in
           or out stream is reset here.
        4. In sctp_process_strreset_resp(), SCTP_STREAM_RESET_INCOMING_SSN or
           OUTGOING event should always be sent for stream reset requests, no
           matter it fails or succeeds to process the request.
      
      Fixes: 81054476 ("sctp: implement receiver-side procedures for the Outgoing SSN Reset Request Parameter")
      Fixes: 16e1a919 ("sctp: implement receiver-side procedures for the Incoming SSN Reset Request Parameter")
      Fixes: 11ae76e6 ("sctp: implement receiver-side procedures for the Reconf Response Parameter")
      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>
      556e554a
    • Xin Long's avatar
      sctp: improve the events for sctp stream adding · f97e7856
      Xin Long authored
      [ Upstream commit 8220c870cb0f4eaa4e335c9645dbd9a1c461c1dd ]
      
      This patch is to improve sctp stream adding events in 2 places:
      
        1. In sctp_process_strreset_addstrm_out(), move up SCTP_MAX_STREAM
           and in stream allocation failure checks, as the adding has to
           succeed after reconf_timer stops for the in stream adding
           request retransmission.
      
        3. In sctp_process_strreset_addstrm_in(), no event should be sent,
           as no in or out stream is added here.
      
      Fixes: 50a41591 ("sctp: implement receiver-side procedures for the Add Outgoing Streams Request Parameter")
      Fixes: c5c4ebb3 ("sctp: implement receiver-side procedures for the Add Incoming Streams Request Parameter")
      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>
      f97e7856
  8. 23 Jan, 2019 1 commit
  9. 09 Jan, 2019 1 commit
    • Xin Long's avatar
      sctp: initialize sin6_flowinfo for ipv6 addrs in sctp_inet6addr_event · a98fbfc3
      Xin Long authored
      [ Upstream commit 4a2eb0c37b4759416996fbb4c45b932500cf06d3 ]
      
      syzbot reported a kernel-infoleak, which is caused by an uninitialized
      field(sin6_flowinfo) of addr->a.v6 in sctp_inet6addr_event().
      The call trace is as below:
      
        BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 lib/usercopy.c:33
        CPU: 1 PID: 8164 Comm: syz-executor2 Not tainted 4.20.0-rc3+ #95
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
        Google 01/01/2011
        Call Trace:
          __dump_stack lib/dump_stack.c:77 [inline]
          dump_stack+0x32d/0x480 lib/dump_stack.c:113
          kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
          kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
          kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
          _copy_to_user+0x19a/0x230 lib/usercopy.c:33
          copy_to_user include/linux/uaccess.h:183 [inline]
          sctp_getsockopt_local_addrs net/sctp/socket.c:5998 [inline]
          sctp_getsockopt+0x15248/0x186f0 net/sctp/socket.c:7477
          sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2937
          __sys_getsockopt+0x489/0x550 net/socket.c:1939
          __do_sys_getsockopt net/socket.c:1950 [inline]
          __se_sys_getsockopt+0xe1/0x100 net/socket.c:1947
          __x64_sys_getsockopt+0x62/0x80 net/socket.c:1947
          do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
          entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      sin6_flowinfo is not really used by SCTP, so it will be fixed by simply
      setting it to 0.
      
      The issue exists since very beginning.
      Thanks Alexander for the reproducer provided.
      
      Reported-by: syzbot+ad5d327e6936a2e284be@syzkaller.appspotmail.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>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a98fbfc3
  10. 17 Dec, 2018 1 commit
  11. 01 Dec, 2018 1 commit
  12. 23 Nov, 2018 2 commits
  13. 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
  14. 18 Oct, 2018 1 commit
  15. 15 Sep, 2018 1 commit
  16. 24 Aug, 2018 1 commit
  17. 11 Jun, 2018 1 commit
  18. 19 May, 2018 5 commits
  19. 29 Apr, 2018 1 commit
  20. 12 Apr, 2018 2 commits
    • 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
    • Eric Dumazet's avatar
      sctp: do not leak kernel memory to user space · 3f80d01b
      Eric Dumazet authored
      
      [ Upstream commit 6780db24 ]
      
      syzbot produced a nice report [1]
      
      Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
      to user space, because sin_zero (padding field) was not properly cleared.
      
      [1]
      BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
      BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227
      CPU: 1 PID: 3586 Comm: syzkaller481044 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
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x4401c9
      RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9
      RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010
      R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0
      R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----addr@___sys_recvmsg
      Variable was created at:
       ___sys_recvmsg+0xd5/0x810 net/socket.c:2172
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
      
      Bytes 8-15 of 16 are uninitialized
      
      ==================================================================
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G    B            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
       panic+0x39d/0x940 kernel/panic.c:183
       kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      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>
      3f80d01b
  21. 09 Mar, 2018 4 commits
    • Alexey Kodanev's avatar
      sctp: fix dst refcnt leak in sctp_v6_get_dst() · 00ec3b0c
      Alexey Kodanev authored
      
      [ Upstream commit 957d761c ]
      
      When going through the bind address list in sctp_v6_get_dst() and
      the previously found address is better ('matchlen > bmatchlen'),
      the code continues to the next iteration without releasing currently
      held destination.
      
      Fix it by releasing 'bdst' before continue to the next iteration, and
      instead of introducing one more '!IS_ERR(bdst)' check for dst_release(),
      move the already existed one right after ip6_dst_lookup_flow(), i.e. we
      shouldn't proceed further if we get an error for the route lookup.
      
      Fixes: dbc2b5e9 ("sctp: fix src address selection if using secondary addresses for ipv6")
      Signed-off-by: 's avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00ec3b0c
    • Xin Long's avatar
      sctp: do not pr_err for the duplicated node in transport rhlist · 36728a6b
      Xin Long authored
      
      [ Upstream commit 27af86bb ]
      
      The pr_err in sctp_hash_transport was supposed to report a sctp bug
      for using rhashtable/rhlist.
      
      The err '-EEXIST' introduced in Commit cd2b7087 ("sctp: check
      duplicate node before inserting a new transport") doesn't belong
      to that case.
      
      So just return -EEXIST back without pr_err any kmsg.
      
      Fixes: cd2b7087 ("sctp: check duplicate node before inserting a new transport")
      Reported-by: 's avatarWei Chen <weichen@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>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36728a6b
    • Tommi Rantala's avatar
      sctp: fix dst refcnt leak in sctp_v4_get_dst · 9f02a069
      Tommi Rantala authored
      
      [ Upstream commit 4a31a6b1 ]
      
      Fix dst reference count leak in sctp_v4_get_dst() introduced in commit
      410f0383 ("sctp: add routing output fallback"):
      
      When walking the address_list, successive ip_route_output_key() calls
      may return the same rt->dst with the reference incremented on each call.
      
      The code would not decrement the dst refcount when the dst pointer was
      identical from the previous iteration, causing the dst refcnt leak.
      
      Testcase:
        ip netns add TEST
        ip netns exec TEST ip link set lo up
        ip link add dummy0 type dummy
        ip link add dummy1 type dummy
        ip link add dummy2 type dummy
        ip link set dev dummy0 netns TEST
        ip link set dev dummy1 netns TEST
        ip link set dev dummy2 netns TEST
        ip netns exec TEST ip addr add 192.168.1.1/24 dev dummy0
        ip netns exec TEST ip link set dummy0 up
        ip netns exec TEST ip addr add 192.168.1.2/24 dev dummy1
        ip netns exec TEST ip link set dummy1 up
        ip netns exec TEST ip addr add 192.168.1.3/24 dev dummy2
        ip netns exec TEST ip link set dummy2 up
        ip netns exec TEST sctp_test -H 192.168.1.2 -P 20002 -h 192.168.1.1 -p 20000 -s -B 192.168.1.3
        ip netns del TEST
      
      In 4.4 and 4.9 kernels this results to:
        [  354.179591] unregister_netdevice: waiting for lo to become free. Usage count = 1
        [  364.419674] unregister_netdevice: waiting for lo to become free. Usage count = 1
        [  374.663664] unregister_netdevice: waiting for lo to become free. Usage count = 1
        [  384.903717] unregister_netdevice: waiting for lo to become free. Usage count = 1
        [  395.143724] unregister_netdevice: waiting for lo to become free. Usage count = 1
        [  405.383645] unregister_netdevice: waiting for lo to become free. Usage count = 1
        ...
      
      Fixes: 410f0383 ("sctp: add routing output fallback")
      Fixes: 0ca50d12 ("sctp: fix src address selection if using secondary addresses")
      Signed-off-by: 's avatarTommi Rantala <tommi.t.rantala@nokia.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>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f02a069
    • Alexey Kodanev's avatar
      sctp: verify size of a new chunk in _sctp_make_chunk() · 1fc74a57
      Alexey Kodanev authored
      
      [ Upstream commit 07f2c7ab ]
      
      When SCTP makes INIT or INIT_ACK packet the total chunk length
      can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when
      transmitting these packets, e.g. the crash on sending INIT_ACK:
      
      [  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
                     put:120156 head:000000007aa47635 data:00000000d991c2de
                     tail:0x1d640 end:0xfec0 dev:<NULL>
      ...
      [  597.976970] ------------[ cut here ]------------
      [  598.033408] kernel BUG at net/core/skbuff.c:104!
      [  600.314841] Call Trace:
      [  600.345829]  <IRQ>
      [  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp]
      [  600.436934]  skb_put+0x16c/0x200
      [  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp]
      [  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp]
      [  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp]
      [  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
      [  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
      [  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
      [  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp]
      [  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
      [  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp]
      [  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
      [  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
      [  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
      [  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
      [  601.284328]  ? sctp_has_association+0x70/0x70 [sctp]
      [  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
      [  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]
      ...
      
      Here the chunk size for INIT_ACK packet becomes too big, mostly
      because of the state cookie (INIT packet has large size with
      many address parameters), plus additional server parameters.
      
      Later this chunk causes the panic in skb_put_data():
      
        skb_packet_transmit()
            sctp_packet_pack()
                skb_put_data(nskb, chunk->skb->data, chunk->skb->len);
      
      'nskb' (head skb) was previously allocated with packet->size
      from u16 'chunk->chunk_hdr->length'.
      
      As suggested by Marcelo we should check the chunk's length in
      _sctp_make_chunk() before trying to allocate skb for it and
      discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.
      Signed-off-by: 's avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leinter@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>
      1fc74a57
  22. 03 Mar, 2018 3 commits
  23. 25 Feb, 2018 2 commits
  24. 03 Feb, 2018 3 commits