Skip to content
  1. May 22, 2017
    • Todd Short's avatar
      Fix infinite loops in secure memory allocation. · ddcccb65
      Todd Short authored
      Remove assertion when mmap() fails.
      Only give the 1<<31 limit test as an example.
      
      Fix the small arena test to just check for the symptom of the infinite
      loop (i.e. initialized set on failure), rather than the actual infinite
      loop. This avoids some valgrind errors.
      
      Backport of:
      PR #3512 commit fee423bb
      PR #3510 commit a486561b
      PR #3455 commit c8e89d58
      PR #3449 commit 7031ddac
      
      
      
      Issue 1:
      
      sh.bittable_size is a size_t but i is and int, which can result in
      freelist == -1 if sh.bittable_size exceeds an int.
      
      This seems to result in an OPENSSL_assert due to invalid allocation
      size, so maybe that is "ok."
      
      Worse, if sh.bittable_size is exactly 1<<31, then this becomes an
      infinite loop (because 1<<31 is a negative int, so it can be shifted
      right forever and sticks at -1).
      
      Issue 2:
      
      CRYPTO_secure_malloc_init() sets secure_mem_initialized=1 even when
      sh_init() returns 0.
      
      If sh_init() fails, we end up with secure_mem_initialized=1 but
      sh.minsize=0. If you then call secure_malloc(), which then calls,
      sh_malloc(), this then enters an infite loop since 0 << anything will
      never be larger than size.
      
      Issue 3:
      
      That same sh_malloc loop will loop forever for a size greater
      than size_t/2 because i will proceed (assuming sh.minsize=16):
      i=16, 32, 64, ..., size_t/8, size_t/4, size_t/2, 0, 0, 0, 0, ....
      This sequence will never be larger than "size".
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3453)
      ddcccb65
    • Diego Santa Cruz's avatar
      Fix srp app missing NULL termination with password callback · 0870b2cd
      Diego Santa Cruz authored
      
      
      The password_callback() function does not necessarily NULL terminate
      the password buffer, the caller must use the returned length but the
      srp app uses this function as if it was doing NULL termination.
      
      This made the -passin and -passout options of "openssl srp"
      fail inexpicably and randomly or even crash.
      
      Fixed by enlarging the buffer by one, so that the maximum password length
      remains unchanged, and adding NULL termination upon return.
      
      [Rearrange code for coding style compliance in process.]
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3475)
      
      (cherry picked from commit 0e83981d)
      0870b2cd
    • Andy Polyakov's avatar
      test/run_tests.pl: don't mask test failures. · c7f6ec9e
      Andy Polyakov authored
      
      
      Switch to TAP::Harness inadvertently masked test failures.
      Test::Harness::runtests was terminating with non-zero exit code in case
      of failure[s], while TAP::Harness apparently holds caller responsible
      for doing so.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      c7f6ec9e
  2. May 21, 2017
  3. May 19, 2017
  4. May 17, 2017
  5. May 15, 2017
  6. May 12, 2017
  7. May 11, 2017
  8. May 10, 2017
  9. May 09, 2017
  10. May 08, 2017
  11. May 05, 2017
  12. May 04, 2017
  13. May 02, 2017
  14. Apr 30, 2017
  15. Apr 28, 2017
  16. Apr 27, 2017
  17. Apr 26, 2017
  18. Apr 25, 2017
    • Andy Polyakov's avatar
      asn1/a_int.c: clean up asn1_get_int64. · 6fc37bee
      Andy Polyakov authored
      
      
      Trouble was that integer negation wasn't producing *formally* correct
      result in platform-neutral sense. Formally correct thing to do is
      -(int64_t)u, but this triggers undefined behaviour for one value that
      would still be representable in ASN.1. The trigger was masked with
      (int64_t)(0-u), but this is formally inappropriate for values other
      than the problematic one. [Also reorder branches to favour most-likely
      paths and harmonize asn1_string_set_int64 with asn1_get_int64].]
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3231)
      
      (cherry picked from commit 786b6a45)
      6fc37bee