1. 07 3月, 2018 1 次提交
  2. 16 1月, 2018 1 次提交
    • D
      sctp: Define usercopy region in SCTP proto slab cache · ab9ee8e3
      David Windsor 提交于
      The SCTP socket event notification subscription information need to be
      copied to/from userspace. In support of usercopy hardening, this patch
      defines a region in the struct proto slab cache in which userspace copy
      operations are allowed. Additionally moves the usercopy fields to be
      adjacent for the region to cover both.
      
      example usage trace:
      
          net/sctp/socket.c:
              sctp_getsockopt_events(...):
                  ...
                  copy_to_user(..., &sctp_sk(sk)->subscribe, len)
      
              sctp_setsockopt_events(...):
                  ...
                  copy_from_user(&sctp_sk(sk)->subscribe, ..., optlen)
      
              sctp_getsockopt_initmsg(...):
                  ...
                  copy_to_user(..., &sctp_sk(sk)->initmsg, len)
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      Signed-off-by: NDavid Windsor <dave@nullcore.net>
      [kees: split from network patch, move struct members adjacent]
      [kees: add SCTPv6 struct whitelist, provide usage trace]
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-sctp@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      ab9ee8e3
  3. 09 1月, 2018 1 次提交
    • M
      sctp: fix the handling of ICMP Frag Needed for too small MTUs · b6c5734d
      Marcelo Ricardo Leitner 提交于
      syzbot reported a hang involving SCTP, on which it kept flooding dmesg
      with the message:
      [  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
      low, using default minimum of 512
      
      That happened because whenever SCTP hits an ICMP Frag Needed, it tries
      to adjust to the new MTU and triggers an immediate retransmission. But
      it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
      allowed (512) would not cause the PMTU to change, and issued the
      retransmission anyway (thus leading to another ICMP Frag Needed, and so
      on).
      
      As IPv4 (ip_rt_min_pmtu=556) and IPv6 (IPV6_MIN_MTU=1280) minimum MTU
      are higher than that, sctp_transport_update_pmtu() is changed to
      re-fetch the PMTU that got set after our request, and with that, detect
      if there was an actual change or not.
      
      The fix, thus, skips the immediate retransmission if the received ICMP
      resulted in no change, in the hope that SCTP will select another path.
      
      Note: The value being used for the minimum MTU (512,
      SCTP_DEFAULT_MINSEGMENT) is not right and instead it should be (576,
      SCTP_MIN_PMTU), but such change belongs to another patch.
      
      Changes from v1:
      - do not disable PMTU discovery, in the light of commit
      06ad3919 ("[SCTP] Don't disable PMTU discovery when mtu is small")
      and as suggested by Xin Long.
      - changed the way to break the rtx loop by detecting if the icmp
        resulted in a change or not
      Changes from v2:
      none
      
      See-also: https://lkml.org/lkml/2017/12/22/811Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6c5734d
  4. 16 12月, 2017 5 次提交
  5. 12 12月, 2017 11 次提交
  6. 11 12月, 2017 1 次提交
    • T
      rhashtable: Change rhashtable_walk_start to return void · 97a6ec4a
      Tom Herbert 提交于
      Most callers of rhashtable_walk_start don't care about a resize event
      which is indicated by a return value of -EAGAIN. So calls to
      rhashtable_walk_start are wrapped wih code to ignore -EAGAIN. Something
      like this is common:
      
             ret = rhashtable_walk_start(rhiter);
             if (ret && ret != -EAGAIN)
                     goto out;
      
      Since zero and -EAGAIN are the only possible return values from the
      function this check is pointless. The condition never evaluates to true.
      
      This patch changes rhashtable_walk_start to return void. This simplifies
      code for the callers that ignore -EAGAIN. For the few cases where the
      caller cares about the resize event, particularly where the table can be
      walked in mulitple parts for netlink or seq file dump, the function
      rhashtable_walk_start_check has been added that returns -EAGAIN on a
      resize event.
      Signed-off-by: NTom Herbert <tom@quantonium.net>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a6ec4a
  7. 02 12月, 2017 1 次提交
  8. 29 11月, 2017 2 次提交
  9. 28 11月, 2017 1 次提交
  10. 18 11月, 2017 1 次提交
    • X
      sctp: set frag_point in sctp_setsockopt_maxseg correctly · ecca8f88
      Xin Long 提交于
      Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with
      val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect.
      
      val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT.
      Then in sctp_datamsg_from_user(), when it's value is greater than cookie
      echo len and trying to bundle with cookie echo chunk, the first_len will
      overflow.
      
      The worse case is when it's value is equal as cookie echo len, first_len
      becomes 0, it will go into a dead loop for fragment later on. In Hangbin
      syzkaller testing env, oom was even triggered due to consecutive memory
      allocation in that loop.
      
      Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should
      deduct the data header for frag_point or user_frag check.
      
      This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting
      the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when
      setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg
      codes.
      Suggested-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reported-by: NHangbin Liu <liuhangbin@gmail.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>
      ecca8f88
  11. 29 10月, 2017 1 次提交
  12. 25 10月, 2017 1 次提交
  13. 04 10月, 2017 5 次提交
    • M
      sctp: introduce round robin stream scheduler · ac1ed8b8
      Marcelo Ricardo Leitner 提交于
      This patch introduces RFC Draft ndata section 3.2 Priority Based
      Scheduler (SCTP_SS_RR).
      
      Works by maintaining a list of enqueued streams and tracking the last
      one used to send data. When the datamsg is done, it switches to the next
      stream.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac1ed8b8
    • M
      sctp: introduce priority based stream scheduler · 637784ad
      Marcelo Ricardo Leitner 提交于
      This patch introduces RFC Draft ndata section 3.4 Priority Based
      Scheduler (SCTP_SS_PRIO).
      
      It works by having a struct sctp_stream_priority for each priority
      configured. This struct is then enlisted on a queue ordered per priority
      if, and only if, there is a stream with data queued, so that dequeueing
      is very straightforward: either finish current datamsg or simply dequeue
      from the highest priority queued, which is the next stream pointed, and
      that's it.
      
      If there are multiple streams assigned with the same priority and with
      data queued, it will do round robin amongst them while respecting
      datamsgs boundaries (when not using idata chunks), to be reasonably
      fair.
      
      We intentionally don't maintain a list of priorities nor a list of all
      streams with the same priority to save memory. The first would mean at
      least 2 other pointers per priority (which, for 1000 priorities, that
      can mean 16kB) and the second would also mean 2 other pointers but per
      stream. As SCTP supports up to 65535 streams on a given asoc, that's
      1MB. This impacts when giving a priority to some stream, as we have to
      find out if the new priority is already being used and if we can free
      the old one, and also when tearing down.
      
      The new fields in struct sctp_stream_out_ext and sctp_stream are added
      under a union because that memory is to be shared with other schedulers.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      637784ad
    • M
      sctp: introduce stream scheduler foundations · 5bbbbe32
      Marcelo Ricardo Leitner 提交于
      This patch introduces the hooks necessary to do stream scheduling, as
      per RFC Draft ndata.  It also introduces the first scheduler, which is
      what we do today but now factored out: first come first served (FCFS).
      
      With stream scheduling now we have to track which chunk was enqueued on
      which stream and be able to select another other than the in front of
      the main outqueue. So we introduce a list on sctp_stream_out_ext
      structure for this purpose.
      
      We reuse sctp_chunk->transmitted_list space for the list above, as the
      chunk cannot belong to the two lists at the same time. By using the
      union in there, we can have distinct names for these moments.
      
      sctp_sched_ops are the operations expected to be implemented by each
      scheduler. The dequeueing is a bit particular to this implementation but
      it is to match how we dequeue packets today. We first dequeue and then
      check if it fits the packet and if not, we requeue it at head. Thus why
      we don't have a peek operation but have dequeue_done instead, which is
      called once the chunk can be safely considered as transmitted.
      
      The check removed from sctp_outq_flush is now performed by
      sctp_stream_outq_migrate, which is only called during assoc setup.
      (sctp_sendmsg() also checks for it)
      
      The only operation that is foreseen but not yet added here is a way to
      signalize that a new packet is starting or that the packet is done, for
      round robin scheduler per packet, but is intentionally left to the
      patch that actually implements it.
      
      Support for I-DATA chunks, also described in this RFC, with user message
      interleaving is straightforward as it just requires the schedulers to
      probe for the feature and ignore datamsg boundaries when dequeueing.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bbbbe32
    • M
      sctp: introduce sctp_chunk_stream_no · 2fc019f7
      Marcelo Ricardo Leitner 提交于
      Add a helper to fetch the stream number from a given chunk.
      Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fc019f7
    • M
      sctp: introduce struct sctp_stream_out_ext · f952be79
      Marcelo Ricardo Leitner 提交于
      With the stream schedulers, sctp_stream_out will become too big to be
      allocated by kmalloc and as we need to allocate with BH disabled, we
      cannot use __vmalloc in sctp_stream_init().
      
      This patch moves out the stats from sctp_stream_out to
      sctp_stream_out_ext, which will be allocated only when the application
      tries to sendmsg something on it.
      
      Just the introduction of sctp_stream_out_ext would already fix the issue
      described above by splitting the allocation in two. Moving the stats
      to it also reduces the pressure on the allocator as we will ask for less
      memory atomically when creating the socket and we will use GFP_KERNEL
      later.
      
      Then, for stream schedulers, we will just use sctp_stream_out_ext.
      Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f952be79
  14. 16 9月, 2017 1 次提交
    • X
      sctp: fix an use-after-free issue in sctp_sock_dump · d25adbeb
      Xin Long 提交于
      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: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d25adbeb
  15. 14 9月, 2017 1 次提交
    • D
      sctp: potential read out of bounds in sctp_ulpevent_type_enabled() · fa5f7b51
      Dan Carpenter 提交于
      This code causes a static checker warning because Smatch doesn't trust
      anything that comes from skb->data.  I've reviewed this code and I do
      think skb->data can be controlled by the user here.
      
      The sctp_event_subscribe struct has 13 __u8 fields and we want to see
      if ours is non-zero.  sn_type can be any value in the 0-USHRT_MAX range.
      We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
      either before the start of the struct or after the end.
      
      This is a very old bug and it's surprising that it would go undetected
      for so long but my theory is that it just doesn't have a big impact so
      it would be hard to notice.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa5f7b51
  16. 12 8月, 2017 6 次提交