This is mostly unrelated to other commits in this PR, except for the
fact that one of the added X.509 tests revealed that with UBSan.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
When passed a zero-length val, the function was free-ing the buffer as
the documentation suggests:
* \param val_len The minimum length of the data buffer needed.
* If this is 0, do not allocate a buffer for the associated
* data.
* If the OID was already present, enlarge, shrink or free
* the existing buffer to fit \p val_len.
However it kept the previous length, leaving the val structure in the
corresponding item in the output list in an inconsistent state:
p == NULL but len != 0
As a result, functions that would try using this item in the list
(including the same function!) afterwards would trip an dereference the
NULL pointer.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The commented out tests cause crashes (in different ways) until the bug
is fixed; the first two test are passing already and are here mostly to
provide a reference point.
The bug report was using programs/x509/cert_write, but string_to_names()
is what it was really targetting, which is better for automated tests.
The strings used are a minor adapation of those from the report.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
I'm just trying to have a shorter name to avoid repeating a long
expression. This is a job for a pointer, not copying a struct.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This version is incomplete. I failed to noticed it when adding a more
complete version, making the existing one redundant.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
That memory leak had been present ever since the san command-line
argument has been added.
Tested that the following invocation is now fully valgrind clean:
programs/x509/cert_write san=DN:C=NL,CN=#0000,CN=foo;DN:CN=#0000,O=foo,OU=bar,C=UK;IP:1.2.3.4;IP:4.3.2.1;URI:http\\://example.org/;URI:foo;DNS:foo.example.org;DNS:bar.example.org
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The runtime error was introduced two commits ago (while avoiding a
use-after-free). Now the programs run cleanly but still leak memory.
The memory leak is long pre-existing and larger than just DN components
(which are made temporarily slightly worse by this commit) and will be
fixed properly in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The documentation doesn't say you can't call these functions more than
once on the same context, and if you do it shouldn't result in a memory
leak. Historically, the call to mbedtls_asn1_free_named_data_list() in
mbedtls_x509_string_to_names() (that was removed in the previous commit)
was ensuring that. Let's restore it where it makes sense. (These are the
only 3 places calling mbedtls_x509_string_to_names() in the library.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now programs/x509/cert_write san="DN:CN=#0000;DN:CN=#0000" is no longer
crashing with use-after-free, instead it's now failing cleanly:
failed
! mbedtls_x509_string_to_names returned -0x2800 - X509 - Input invalid
That's better of course but still not great, will be fixed by future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This structure is initialized during the compilation and there is no
reason it changes.
Making it const allows the compiler to put it in .rodata section instead
of .data one.
Signed-off-by: Xavier Chapron <chapron.xavier@gmail.com>
Previously, the length of the label was limited to the maximal length
that would be used in the TLS 1.3 key schedule. With the keying material
exporter, labels of up to 249 bytes may be used.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The openssl version in the docker image doesn't support TLS 1.3, so we
can't run the test.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
