1. 26 12月, 2021 1 次提交
    • X
      sctp: use call_rcu to free endpoint · 5ec7d18d
      Xin Long 提交于
      This patch is to delay the endpoint free by calling call_rcu() to fix
      another use-after-free issue in sctp_sock_dump():
      
        BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20
        Call Trace:
          __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218
          lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
          __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
          _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
          spin_lock_bh include/linux/spinlock.h:334 [inline]
          __lock_sock+0x203/0x350 net/core/sock.c:2253
          lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
          lock_sock include/net/sock.h:1492 [inline]
          sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
          sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091
          sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
          __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
          inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
          netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244
          __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352
          netlink_dump_start include/linux/netlink.h:216 [inline]
          inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
          __sock_diag_cmd net/core/sock_diag.c:232 [inline]
          sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
          netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477
          sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274
      
      This issue occurs when asoc is peeled off and the old sk is freed after
      getting it by asoc->base.sk and before calling lock_sock(sk).
      
      To prevent the sk free, as a holder of the sk, ep should be alive when
      calling lock_sock(). This patch uses call_rcu() and moves sock_put and
      ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to
      hold the ep under rcu_read_lock in sctp_transport_traverse_process().
      
      If sctp_endpoint_hold() returns true, it means this ep is still alive
      and we have held it and can continue to dump it; If it returns false,
      it means this ep is dead and can be freed after rcu_read_unlock, and
      we should skip it.
      
      In sctp_sock_dump(), after locking the sk, if this ep is different from
      tsp->asoc->ep, it means during this dumping, this asoc was peeled off
      before calling lock_sock(), and the sk should be skipped; If this ep is
      the same with tsp->asoc->ep, it means no peeloff happens on this asoc,
      and due to lock_sock, no peeloff will happen either until release_sock.
      
      Note that delaying endpoint free won't delay the port release, as the
      port release happens in sctp_endpoint_destroy() before calling call_rcu().
      Also, freeing endpoint by call_rcu() makes it safe to access the sk by
      asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
      
      Thanks Jones to bring this issue up.
      
      v1->v2:
        - improve the changelog.
        - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.
      
      Reported-by: syzbot+9276d76e83e3bcde6c99@syzkaller.appspotmail.com
      Reported-by: NLee Jones <lee.jones@linaro.org>
      Fixes: d25adbeb ("sctp: fix an use-after-free issue in sctp_sock_dump")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ec7d18d
  2. 03 11月, 2021 1 次提交
  3. 19 7月, 2021 1 次提交
    • X
      sctp: trim optlen when it's a huge value in sctp_setsockopt · 2f3fdd8d
      Xin Long 提交于
      After commit ca84bd05 ("sctp: copy the optval from user space in
      sctp_setsockopt"), it does memory allocation in sctp_setsockopt with
      the optlen, and it would fail the allocation and return error if the
      optlen from user space is a huge value.
      
      This breaks some sockopts, like SCTP_HMAC_IDENT, SCTP_RESET_STREAMS and
      SCTP_AUTH_KEY, as when processing these sockopts before, optlen would
      be trimmed to a biggest value it needs when optlen is a huge value,
      instead of failing the allocation and returning error.
      
      This patch is to fix the allocation failure when it's a huge optlen from
      user space by trimming it to the biggest size sctp sockopt may need when
      necessary, and this biggest size is from sctp_setsockopt_reset_streams()
      for SCTP_RESET_STREAMS, which is bigger than those for SCTP_HMAC_IDENT
      and SCTP_AUTH_KEY.
      
      Fixes: ca84bd05 ("sctp: copy the optval from user space in sctp_setsockopt")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f3fdd8d
  4. 23 6月, 2021 3 次提交
  5. 26 5月, 2021 1 次提交
  6. 04 5月, 2021 2 次提交
    • X
      sctp: delay auto_asconf init until binding the first addr · 34e5b011
      Xin Long 提交于
      As Or Cohen described:
      
        If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock
        held and sp->do_auto_asconf is true, then an element is removed
        from the auto_asconf_splist without any proper locking.
      
        This can happen in the following functions:
        1. In sctp_accept, if sctp_sock_migrate fails.
        2. In inet_create or inet6_create, if there is a bpf program
           attached to BPF_CGROUP_INET_SOCK_CREATE which denies
           creation of the sctp socket.
      
      This patch is to fix it by moving the auto_asconf init out of
      sctp_init_sock(), by which inet_create()/inet6_create() won't
      need to operate it in sctp_destroy_sock() when calling
      sk_common_release().
      
      It also makes more sense to do auto_asconf init while binding the
      first addr, as auto_asconf actually requires an ANY addr bind,
      see it in sctp_addr_wq_timeout_handler().
      
      This addresses CVE-2021-23133.
      
      Fixes: 61023658 ("bpf: Add new cgroup attach type to enable sock modifications")
      Reported-by: NOr Cohen <orcohen@paloaltonetworks.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34e5b011
    • X
      Revert "net/sctp: fix race condition in sctp_destroy_sock" · 01bfe5e8
      Xin Long 提交于
      This reverts commit b166a20b.
      
      This one has to be reverted as it introduced a dead lock, as
      syzbot reported:
      
             CPU0                    CPU1
             ----                    ----
        lock(&net->sctp.addr_wq_lock);
                                     lock(slock-AF_INET6);
                                     lock(&net->sctp.addr_wq_lock);
        lock(slock-AF_INET6);
      
      CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1
      is that of sctp_close().
      
      The original issue this commit fixed will be fixed in the next
      patch.
      
      Reported-by: syzbot+959223586843e69a2674@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01bfe5e8
  7. 14 4月, 2021 1 次提交
  8. 29 3月, 2021 1 次提交
  9. 31 10月, 2020 3 次提交
    • X
      sctp: add udphdr to overhead when udp_port is set · f1bfe8b5
      Xin Long 提交于
      sctp_mtu_payload() is for calculating the frag size before making
      chunks from a msg. So we should only add udphdr size to overhead
      when udp socks are listening, as only then sctp can handle the
      incoming sctp over udp packets and outgoing sctp over udp packets
      will be possible.
      
      Note that we can't do this according to transport->encap_port, as
      different transports may be set to different values, while the
      chunks were made before choosing the transport, we could not be
      able to meet all rfc6951#section-5.6 recommends.
      
      v1->v2:
        - Add udp_port for sctp_sock to avoid a potential race issue, it
          will be used in xmit path in the next patch.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f1bfe8b5
    • X
      sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt · 8dba2960
      Xin Long 提交于
      This patch is to implement:
      
        rfc6951#section-6.1: Get or Set the Remote UDP Encapsulation Port Number
      
      with the param of the struct:
      
        struct sctp_udpencaps {
          sctp_assoc_t sue_assoc_id;
          struct sockaddr_storage sue_address;
          uint16_t sue_port;
        };
      
      the encap_port of sock, assoc or transport can be changed by users,
      which also means it allows the different transports of the same asoc
      to have different encap_port value.
      
      v1->v2:
        - no change.
      v2->v3:
        - fix the endian warning when setting values between encap_port and
          sue_port.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8dba2960
    • X
      sctp: add encap_port for netns sock asoc and transport · e8a3001c
      Xin Long 提交于
      encap_port is added as per netns/sock/assoc/transport, and the
      latter one's encap_port inherits the former one's by default.
      The transport's encap_port value would mostly decide if one
      packet should go out with udp encapsulated or not.
      
      This patch also allows users to set netns' encap_port by sysctl.
      
      v1->v2:
        - Change to define encap_port as __be16 for sctp_sock, asoc and
          transport.
      v2->v3:
        - No change.
      v3->v4:
        - Add 'encap_port' entry in ip-sysctl.rst.
      v4->v5:
        - Improve the description of encap_port in ip-sysctl.rst.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      e8a3001c
  10. 21 9月, 2020 1 次提交
  11. 25 8月, 2020 1 次提交
    • X
      sctp: not disable bh in the whole sctp_get_port_local() · 3106ecb4
      Xin Long 提交于
      With disabling bh in the whole sctp_get_port_local(), when
      snum == 0 and too many ports have been used, the do-while
      loop will take the cpu for a long time and cause cpu stuck:
      
        [ ] watchdog: BUG: soft lockup - CPU#11 stuck for 22s!
        [ ] RIP: 0010:native_queued_spin_lock_slowpath+0x4de/0x940
        [ ] Call Trace:
        [ ]  _raw_spin_lock+0xc1/0xd0
        [ ]  sctp_get_port_local+0x527/0x650 [sctp]
        [ ]  sctp_do_bind+0x208/0x5e0 [sctp]
        [ ]  sctp_autobind+0x165/0x1e0 [sctp]
        [ ]  sctp_connect_new_asoc+0x355/0x480 [sctp]
        [ ]  __sctp_connect+0x360/0xb10 [sctp]
      
      There's no need to disable bh in the whole function of
      sctp_get_port_local. So fix this cpu stuck by removing
      local_bh_disable() called at the beginning, and using
      spin_lock_bh() instead.
      
      The same thing was actually done for inet_csk_get_port() in
      Commit ea8add2b ("tcp/dccp: better use of ephemeral
      ports in bind()").
      
      Thanks to Marcelo for pointing the buggy code out.
      
      v1->v2:
        - use cond_resched() to yield cpu to other tasks if needed,
          as Eric noticed.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: NYing Xu <yinxu@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3106ecb4
  12. 25 7月, 2020 2 次提交
  13. 20 7月, 2020 22 次提交