An embedded item wasn't allocated separately on the heap, so don't
free it as if it was.
Issue discovered by Pavel Kopyl
(Imported from upstream's cdc3307d4257f4fcebbab3b2b44207e1a399da05 and
65d414434aeecd5aa86a46adbfbcb59b4344503a.)
I do not believe this is actually reachable in BoringSSL, even in the
face of malloc errors. The only field which sets ASN1_TFLG_COMBINE is in
X509_ATTRIBUTE. That field's value is X509_ATTRIBUTE_SET which cannot
fail to initialize. (It is a CHOICE whose initialization consists of
setting the selector to -1 and calling the type's callback which is
unset for this type.)
Change-Id: I29c080f8a4ddc2f3ef9c119d0d90a899d3cb78c5
Reviewed-on: https://boringssl-review.googlesource.com/22365
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
asn1_template_noexp_d2i call ASN1_item_ex_free(&skfield,...) on error.
Reworked error handling in asn1_item_ex_combine_new:
- call ASN1_item_ex_free and return the correct error code if
ASN1_template_new failed.
- dont call ASN1_item_ex_free if ASN1_OP_NEW_PRE failed.
Reworked error handing in x509_name_ex_d2i and x509_name_encode.
(Imported from upstream's 748cb9a17f4f2b77aad816cf658cd4025dc847ee.)
I believe the tasn1_new.c change is a no-op since we have no
ASN1_OP_NEW_PRE hooks anymore. I'm not sure what the commit message is
referring to with ASN1_template_new. It also seems odd as
ASN1_item_ex_free should probably be able to survive *pval being NULL.
Whatever.
We'd previously tried to fix x509_name_ex_d2i, but I think ours wasn't
quite right. (This thing is a mess...) I've aligned that function with
upstream.
Change-Id: Ie71521cd8a1ec357876caadd13be1ce247110f76
Reviewed-on: https://boringssl-review.googlesource.com/13831
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Most C standard library functions are undefined if passed NULL, even
when the corresponding length is zero. This gives them (and, in turn,
all functions which call them) surprising behavior on empty arrays.
Some compilers will miscompile code due to this rule. See also
https://www.imperialviolet.org/2016/06/26/nonnull.html
Add OPENSSL_memcpy, etc., wrappers which avoid this problem.
BUG=23
Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e
Reviewed-on: https://boringssl-review.googlesource.com/12928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL upstream did a bulk reformat. We still have some files that have
the old OpenSSL style and this makes applying patches to them more
manual, and thus more error-prone, than it should be.
This change is the result of running
util/openssl-format-source -v -c .
in the enumerated directories. A few files were in BoringSSL style and
have not been touched.
This change should be formatting only; no semantic difference.
Change-Id: I75ced2970ae22b9facb930a79798350a09c5111e
Reviewed-on: https://boringssl-review.googlesource.com/6904
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This change converts the reference counts in crypto/ to use
|CRYPTO_refcount_t|. The reference counts in |X509_PKEY| and |X509_INFO|
were never actually used and so were dropped.
Change-Id: I75d572cdac1f8c1083c482e29c9519282d7fd16c
Reviewed-on: https://boringssl-review.googlesource.com/4772
Reviewed-by: Adam Langley <agl@google.com>
While *pval is usually a pointer in rare circumstances it can be a long
value. One some platforms (e.g. WIN64) where
sizeof(long) < sizeof(ASN1_VALUE *) this will write past the field.
*pval is initialised correctly in the rest of ASN1_item_ex_new so setting it
to NULL is unecessary anyway.
Thanks to Julien Kauffmann for reporting this issue.
(Imported from upstream's f617b4969a9261b9d7d381670aefbe2cf766a2cb.)
Change-Id: I8cc777f7ab126dcef3a0278a82d3fc91faf4c231
Reviewed-on: https://boringssl-review.googlesource.com/4510
Reviewed-by: Adam Langley <agl@google.com>
ASN1_primitive_new takes an ASN1_ITEM * param |it|. There are a couple
of conditional code paths that check whether |it| is NULL or not - but
later |it| is deref'd unconditionally. If |it| was ever really NULL then
this would seg fault. In practice ASN1_primitive_new is marked as an
internal function in the public header file. The only places it is ever
used internally always pass a non NULL parameter for |it|. Therefore, change
the code to sanity check that |it| is not NULL, and remove the conditional
checking.
(Imported from upstream's 9e488fd6ab2c295941e91a47ab7bcd346b7540c7)
Change-Id: Icbb13cd00d0ec5529871b678b0bcc465956a7572
Reviewed-on: https://boringssl-review.googlesource.com/4006
Reviewed-by: Adam Langley <agl@google.com>
Caught by malloc valgrind tests on Basic-Client-Sync. Also one by inspection
and verified with valgrind. Those should pass now with the exception of
CRYPTO_free_ex_data being internally implemented with malloc.
(Clearly we next should make our malloc tests assert that the containing
function fails to catch when we fail to check for some error and things
silently move one.)
Change-Id: I56c51dc8a32a7d3c7ac907d54015dc241728c761
Reviewed-on: https://boringssl-review.googlesource.com/3440
Reviewed-by: Adam Langley <agl@google.com>
Including string.h in base.h causes any file that includes a BoringSSL
header to include string.h. Generally this wouldn't be a problem,
although string.h might slow down the compile if it wasn't otherwise
needed. However, it also causes problems for ipsec-tools in Android
because OpenSSL didn't have this behaviour.
This change removes string.h from base.h and, instead, adds it to each
.c file that requires it.
Change-Id: I5968e50b0e230fd3adf9b72dd2836e6f52d6fb37
Reviewed-on: https://boringssl-review.googlesource.com/3200
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
