1. 29 1月, 2008 20 次提交
  2. 09 1月, 2008 3 次提交
  3. 21 12月, 2007 1 次提交
  4. 17 12月, 2007 1 次提交
  5. 07 12月, 2007 2 次提交
  6. 29 11月, 2007 5 次提交
  7. 20 11月, 2007 1 次提交
  8. 12 11月, 2007 1 次提交
    • J
      Fix memory leak in discard case of sctp_sf_abort_violation() · 9abed245
      Jesper Juhl 提交于
      In net/sctp/sm_statefuns.c::sctp_sf_abort_violation() we may leak
      the storage allocated for 'abort' by returning from the function
      without using or freeing it. This happens in case
      "sctp_auth_recv_cid(SCTP_CID_ABORT, asoc)" is true and we jump to
      the 'discard' label.
      Spotted by the Coverity checker.
      
      The simple fix is to simply move the creation of the "abort chunk"
      to after the possible jump to the 'discard' label. This way we don't
      even have to allocate the memory at all in the problem case.
      Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      9abed245
  9. 10 11月, 2007 5 次提交
  10. 08 11月, 2007 1 次提交
    • V
      SCTP: Fix a potential race between timers and receive path. · 027f6e1a
      Vlad Yasevich 提交于
      There is a possible race condition where the timer code will
      free the association and the next packet in the queue will also
      attempt to free the same association.
      
      The example is, when we receive an ABORT at about the same time
      as the retransmission timer fires.  If the timer wins the race,
      it will free the association.  Once it releases the lock, the
      queue processing will recieve the ABORT and will try to free
      the association again.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      027f6e1a