Skip to content
  1. Aug 19, 2016
    • Matt Caswell's avatar
      Fix DTLS unprocessed records bug · fa755697
      Matt Caswell authored
      
      
      During a DTLS handshake we may get records destined for the next epoch
      arrive before we have processed the CCS. In that case we can't decrypt or
      verify the record yet, so we buffer it for later use. When we do receive
      the CCS we work through the queue of unprocessed records and process them.
      
      Unfortunately the act of processing wipes out any existing packet data
      that we were still working through. This includes any records from the new
      epoch that were in the same packet as the CCS. We should only process the
      buffered records if we've not got any data left.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      fa755697
  2. Aug 16, 2016
  3. Aug 15, 2016
  4. Aug 05, 2016
  5. Aug 04, 2016
  6. Aug 03, 2016
  7. Aug 02, 2016
  8. Jul 22, 2016
    • Dr. Stephen Henson's avatar
      Fix OOB read in TS_OBJ_print_bio(). · 6adf409c
      Dr. Stephen Henson authored
      
      
      TS_OBJ_print_bio() misuses OBJ_txt2obj: it should print the result
      as a null terminated buffer. The length value returned is the total
      length the complete text reprsentation would need not the amount of
      data written.
      
      CVE-2016-2180
      
      Thanks to Shi Lei for reporting this bug.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (cherry picked from commit 0ed26acc)
      6adf409c
  9. Jun 30, 2016
  10. Jun 29, 2016
  11. Jun 27, 2016
  12. Jun 07, 2016
  13. Jun 06, 2016
  14. Jun 03, 2016
  15. Jun 01, 2016
    • Matt Caswell's avatar
      Avoid some undefined pointer arithmetic · 6f35f6de
      Matt Caswell authored
      
      
      A common idiom in the codebase is:
      
      if (p + len > limit)
      {
          return; /* Too long */
      }
      
      Where "p" points to some malloc'd data of SIZE bytes and
      limit == p + SIZE
      
      "len" here could be from some externally supplied data (e.g. from a TLS
      message).
      
      The rules of C pointer arithmetic are such that "p + len" is only well
      defined where len <= SIZE. Therefore the above idiom is actually
      undefined behaviour.
      
      For example this could cause problems if some malloc implementation
      provides an address for "p" such that "p + len" actually overflows for
      values of len that are too big and therefore p + len < limit!
      
      Issue reported by Guido Vranken.
      
      CVE-2016-2177
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      6f35f6de
  16. May 26, 2016
  17. May 23, 2016
  18. May 19, 2016
  19. May 11, 2016
  20. May 09, 2016
  21. May 06, 2016
  22. May 05, 2016
  23. May 04, 2016
  24. May 03, 2016