1. 23 11月, 2018 1 次提交
  2. 12 8月, 2018 2 次提交
  3. 28 4月, 2018 1 次提交
  4. 15 2月, 2018 1 次提交
  5. 04 1月, 2018 1 次提交
  6. 16 12月, 2017 2 次提交
  7. 12 12月, 2017 1 次提交
    • X
      sctp: implement make_datafrag for sctp_stream_interleave · 0c3f6f65
      Xin Long 提交于
      To avoid hundreds of checks for the different process on I-DATA chunk,
      struct sctp_stream_interleave is defined as a group of functions used
      to replace the codes in some place where it needs to do different job
      according to if the asoc intl_enabled is set.
      
      With these ops, it only needs to initialize asoc->stream.si with
      sctp_stream_interleave_0 for normal data if asoc intl_enable is 0,
      or sctp_stream_interleave_1 for idata if asoc intl_enable is set in
      sctp_stream_init.
      
      After that, the members in asoc->stream.si can be used directly in
      some special places without checking asoc intl_enable.
      
      make_datafrag is the first member for sctp_stream_interleave, it's
      used to make data or idata frags, called in sctp_datamsg_from_user.
      The old function sctp_make_datafrag_empty needs to be adjust some
      to fit in this ops.
      
      Note that as idata and data chunks have different length, it also
      defines data_chunk_len for sctp_stream_interleave to describe the
      chunk size.
      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>
      0c3f6f65
  8. 29 11月, 2017 1 次提交
  9. 27 11月, 2017 5 次提交
  10. 16 11月, 2017 1 次提交
    • X
      sctp: check stream reset info len before making reconf chunk · 423852f8
      Xin Long 提交于
      Now when resetting stream, if both in and out flags are set, the info
      len can reach:
        sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) +
        sizeof(struct sctp_strreset_inreq)  + SCTP_MAX_STREAM(65535)
      even without duplicated stream no, this value is far greater than the
      chunk's max size.
      
      _sctp_make_chunk doesn't do any check for this, which would cause the
      skb it allocs is huge, syzbot even reported a crash due to this.
      
      This patch is to check stream reset info len before making reconf
      chunk and return EINVAL if the len exceeds chunk's capacity.
      
      Thanks Marcelo and Neil for making this clear.
      
      v1->v2:
        - move the check into sctp_send_reset_streams instead.
      
      Fixes: cc16f00f ("sctp: add support for generating stream reconf ssn reset request chunk")
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      423852f8
  11. 01 11月, 2017 1 次提交
  12. 29 10月, 2017 1 次提交
  13. 04 10月, 2017 5 次提交
  14. 02 7月, 2017 1 次提交
  15. 03 6月, 2017 2 次提交
  16. 19 4月, 2017 3 次提交
    • X
      sctp: process duplicated strreset asoc request correctly · 6c801387
      Xin Long 提交于
      This patch is to fix the replay attack issue for strreset asoc requests.
      
      When a duplicated strreset asoc request is received, reply it with bad
      seqno if it's seqno < asoc->strreset_inseq - 2, and reply it with the
      result saved in asoc if it's seqno >= asoc->strreset_inseq - 2.
      
      But note that if the result saved in asoc is performed, the sender's next
      tsn and receiver's next tsn for the response chunk should be set. It's
      safe to get them from asoc. Because if it's changed, which means the peer
      has received the response already, the new response with wrong tsn won't
      be accepted by peer.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c801387
    • X
      sctp: process duplicated strreset in and addstrm in requests correctly · d0f025e6
      Xin Long 提交于
      This patch is to fix the replay attack issue for strreset and addstrm in
      requests.
      
      When a duplicated strreset in or addstrm in request is received, reply it
      with bad seqno if it's seqno < asoc->strreset_inseq - 2, and reply it with
      the result saved in asoc if it's seqno >= asoc->strreset_inseq - 2.
      
      For strreset in or addstrm in request, if the receiver side processes it
      successfully, a strreset out or addstrm out request(as a response for that
      request) will be sent back to peer. reconf_time will retransmit the out
      request even if it's lost.
      
      So when receiving a duplicated strreset in or addstrm in request and it's
      result was performed, it shouldn't reply this request, but drop it instead.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0f025e6
    • X
      sctp: process duplicated strreset out and addstrm out requests correctly · e4dc99c7
      Xin Long 提交于
      Now sctp stream reconf will process a request again even if it's seqno is
      less than asoc->strreset_inseq.
      
      If one request has been done successfully and some data chunks have been
      accepted and then a duplicated strreset out request comes, the streamin's
      ssn will be cleared. It will cause that stream will never receive chunks
      any more because of unsynchronized ssn. It allows a replay attack.
      
      A similar issue also exists when processing addstrm out requests. It will
      cause more extra streams being added.
      
      This patch is to fix it by saving the last 2 results into asoc. When a
      duplicated strreset out or addstrm out request is received, reply it with
      bad seqno if it's seqno < asoc->strreset_inseq - 2, and reply it with the
      result saved in asoc if it's seqno >= asoc->strreset_inseq - 2.
      
      Note that it saves last 2 results instead of only last 1 result, because
      two requests can be sent together in one chunk.
      
      And note that when receiving a duplicated request, the receiver side will
      still reply it even if the peer has received the response. It's safe, As
      the response will be dropped by the peer.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4dc99c7
  17. 18 4月, 2017 1 次提交
  18. 31 3月, 2017 1 次提交
    • X
      sctp: alloc stream info when initializing asoc · 3dbcc105
      Xin Long 提交于
      When sending a msg without asoc established, sctp will send INIT packet
      first and then enqueue chunks.
      
      Before receiving INIT_ACK, stream info is not yet alloced. But enqueuing
      chunks needs to access stream info, like out stream state and out stream
      cnt.
      
      This patch is to fix it by allocing out stream info when initializing an
      asoc, allocing in stream and re-allocing out stream when processing init.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dbcc105
  19. 13 3月, 2017 4 次提交
  20. 20 2月, 2017 2 次提交
  21. 10 2月, 2017 3 次提交