1. 19 3月, 2019 3 次提交
    • X
      sctp: fix ignoring asoc_id for tcp-style sockets on SCTP_DELAYED_SACK sockopt · 8e2614fc
      Xin Long 提交于
      A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
      SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DELAYED_SACK sockopt.
      
      Fixes: 9c5829e1 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DELAYED_SACK sockopt")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e2614fc
    • M
      sctp: fix ignoring asoc_id for tcp-style sockets on SCTP_DEFAULT_SEND_PARAM sockopt · 1354e72f
      Marcelo Ricardo Leitner 提交于
      Currently if the user pass an invalid asoc_id to SCTP_DEFAULT_SEND_PARAM
      on a TCP-style socket, it will silently ignore the new parameters.
      That's because after not finding an asoc, it is checking asoc_id against
      the known values of CURRENT/FUTURE/ALL values and that fails to match.
      
      IOW, if the user supplies an invalid asoc id or not, it should either
      match the current asoc or the socket itself so that it will inherit
      these later. Fixes it by forcing asoc_id to SCTP_FUTURE_ASSOC in case it
      is a TCP-style socket without an asoc, so that the values get set on the
      socket.
      
      Fixes: 707e45b3 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SEND_PARAM sockopt")
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1354e72f
    • X
      sctp: not copy sctp_sock pd_lobby in sctp_copy_descendant · 636d25d5
      Xin Long 提交于
      Now sctp_copy_descendant() copies pd_lobby from old sctp scok to new
      sctp sock. If sctp_sock_migrate() returns error, it will panic when
      releasing new sock and trying to purge pd_lobby due to the incorrect
      pointers in pd_lobby.
      
        [  120.485116] kasan: CONFIG_KASAN_INLINE enabled
        [  120.486270] kasan: GPF could be caused by NULL-ptr deref or user
        [  120.509901] Call Trace:
        [  120.510443]  sctp_ulpevent_free+0x1e8/0x490 [sctp]
        [  120.511438]  sctp_queue_purge_ulpevents+0x97/0xe0 [sctp]
        [  120.512535]  sctp_close+0x13a/0x700 [sctp]
        [  120.517483]  inet_release+0xdc/0x1c0
        [  120.518215]  __sock_release+0x1d2/0x2a0
        [  120.519025]  sctp_do_peeloff+0x30f/0x3c0 [sctp]
      
      We fix it by not copying sctp_sock pd_lobby in sctp_copy_descendan(),
      and skb_queue_head_init() can also be removed in sctp_sock_migrate().
      
      Reported-by: syzbot+85e0b422ff140b03672a@syzkaller.appspotmail.com
      Fixes: 89664c62 ("sctp: sctp_sock_migrate() returns error if sctp_bind_addr_dup() fails")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      636d25d5
  2. 09 3月, 2019 2 次提交
    • X
      sctp: call sctp_auth_init_hmacs() in sctp_sock_migrate() · c6f33e05
      Xin Long 提交于
      New ep's auth_hmacs should be set if old ep's is set, in case that
      net->sctp.auth_enable has been changed to 0 by users and new ep's
      auth_hmacs couldn't be set in sctp_endpoint_init().
      
      It can even crash kernel by doing:
      
        1. on server: sysctl -w net.sctp.auth_enable=1,
                      sysctl -w net.sctp.addip_enable=1,
                      sysctl -w net.sctp.addip_noauth_enable=0,
                      listen() on server,
                      sysctl -w net.sctp.auth_enable=0.
        2. on client: connect() to server.
        3. on server: accept() the asoc,
                      sysctl -w net.sctp.auth_enable=1.
        4. on client: send() asconf packet to server.
      
      The call trace:
      
        [  245.280251] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        [  245.286872] RIP: 0010:sctp_auth_calculate_hmac+0xa3/0x140 [sctp]
        [  245.304572] Call Trace:
        [  245.305091]  <IRQ>
        [  245.311287]  sctp_sf_authenticate+0x110/0x160 [sctp]
        [  245.312311]  sctp_sf_eat_auth+0xf2/0x230 [sctp]
        [  245.313249]  sctp_do_sm+0x9a/0x2d0 [sctp]
        [  245.321483]  sctp_assoc_bh_rcv+0xed/0x1a0 [sctp]
        [  245.322495]  sctp_rcv+0xa66/0xc70 [sctp]
      
      It's because the old ep->auth_hmacs wasn't copied to the new ep while
      ep->auth_hmacs is used in sctp_auth_calculate_hmac() when processing
      the incoming auth chunks, and it should have been done when migrating
      sock.
      Reported-by: NYing Xu <yinxu@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6f33e05
    • X
      sctp: sctp_sock_migrate() returns error if sctp_bind_addr_dup() fails · 89664c62
      Xin Long 提交于
      It should fail to create the new sk if sctp_bind_addr_dup() fails
      when accepting or peeloff an association.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89664c62
  3. 05 3月, 2019 1 次提交
  4. 02 2月, 2019 1 次提交
  5. 30 1月, 2019 24 次提交
  6. 06 12月, 2018 1 次提交
  7. 20 11月, 2018 4 次提交
  8. 13 11月, 2018 2 次提交
  9. 30 10月, 2018 1 次提交
  10. 19 10月, 2018 1 次提交
    • X
      sctp: use sk_wmem_queued to check for writable space · cd305c74
      Xin Long 提交于
      sk->sk_wmem_queued is used to count the size of chunks in out queue
      while sk->sk_wmem_alloc is for counting the size of chunks has been
      sent. sctp is increasing both of them before enqueuing the chunks,
      and using sk->sk_wmem_alloc to check for writable space.
      
      However, sk_wmem_alloc is also increased by 1 for the skb allocked
      for sending in sctp_packet_transmit() but it will not wake up the
      waiters when sk_wmem_alloc is decreased in this skb's destructor.
      
      If msg size is equal to sk_sndbuf and sendmsg is waiting for sndbuf,
      the check 'msg_len <= sctp_wspace(asoc)' in sctp_wait_for_sndbuf()
      will keep waiting if there's a skb allocked in sctp_packet_transmit,
      and later even if this skb got freed, the waiting thread will never
      get waked up.
      
      This issue has been there since very beginning, so we change to use
      sk->sk_wmem_queued to check for writable space as sk_wmem_queued is
      not increased for the skb allocked for sending, also as TCP does.
      
      SOCK_SNDBUF_LOCK check is also removed here as it's for tx buf auto
      tuning which I will add in another patch.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd305c74