1. 26 4月, 2018 1 次提交
  2. 15 3月, 2018 2 次提交
    • X
      sctp: add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT · ec2e506c
      Xin Long 提交于
      This patch is to add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT,
      as described in section 6.1.8 of RFC6458.
      
            SCTP_AUTH_FREE_KEY:  This report indicates that the SCTP
               implementation will no longer use the key identifier specified
               in auth_keynumber.
      
      After deactivating a key, it would never be used again, which means
      it's refcnt can't be held/increased by new chunks. But there may be
      some chunks in out queue still using it. So only when refcnt is 1,
      which means no chunk in outqueue is using/holding this key either,
      this EVENT would be sent.
      
      When users receive this notification, they could do DEL_KEY sockopt to
      remove this shkey, and also tell the peer that this key won't be used
      in any chunk thoroughly from now on, then the peer can remove it as
      well safely.
      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>
      ec2e506c
    • X
      sctp: add refcnt support for sh_key · 1b1e0bc9
      Xin Long 提交于
      With refcnt support for sh_key, chunks auth sh_keys can be decided
      before enqueuing it. Changing the active key later will not affect
      the chunks already enqueued.
      
      Furthermore, this is necessary when adding the support for authinfo
      for sendmsg in next patch.
      
      Note that struct sctp_chunk can't be grown due to that performance
      drop issue on slow cpu, so it just reuses head_skb memory for shkey
      in sctp_chunk.
      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>
      1b1e0bc9
  3. 27 2月, 2018 1 次提交
  4. 10 2月, 2018 1 次提交
    • A
      sctp: verify size of a new chunk in _sctp_make_chunk() · 07f2c7ab
      Alexey Kodanev 提交于
      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: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leinter@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07f2c7ab
  5. 16 1月, 2018 1 次提交
  6. 16 12月, 2017 1 次提交
  7. 12 12月, 2017 3 次提交
  8. 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
  9. 29 10月, 2017 2 次提交
  10. 12 8月, 2017 2 次提交
  11. 07 8月, 2017 2 次提交
  12. 04 8月, 2017 8 次提交
  13. 25 7月, 2017 1 次提交
  14. 17 7月, 2017 5 次提交
  15. 15 7月, 2017 1 次提交
    • X
      sctp: fix an array overflow when all ext chunks are set · 10b3bf54
      Xin Long 提交于
      Marcelo noticed an array overflow caused by commit c28445c3
      ("sctp: add reconf_enable in asoc ep and netns"), in which sctp
      would add SCTP_CID_RECONF into extensions when reconf_enable is
      set in sctp_make_init and sctp_make_init_ack.
      
      Then now when all ext chunks are set, 4 ext chunk ids can be put
      into extensions array while extensions array size is 3. It would
      cause a kernel panic because of this overflow.
      
      This patch is to fix it by defining extensions array size is 4 in
      both sctp_make_init and sctp_make_init_ack.
      
      Fixes: c28445c3 ("sctp: add reconf_enable in asoc ep and netns")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10b3bf54
  16. 05 7月, 2017 1 次提交
  17. 02 7月, 2017 6 次提交
  18. 21 6月, 2017 1 次提交