RFC 5280 defines cA as BOOLEAN DEFAULT FALSE, so a basicConstraints
extension containing only pathLenConstraint (SEQUENCE { INTEGER n })
is syntactically valid and must be interpreted as cA=FALSE. The fix
for CVE-2026-49300 rejected this encoding outright, breaking
compatibility with certificates emitted by devices such as
Eaton/CODESYS PLCs.
Tolerate MBEDTLS_ERR_ASN1_UNEXPECTED_TAG from the cA BOOLEAN parse,
keeping cA FALSE and letting the existing INTEGER parser validate
pathLenConstraint. The INTEGER value is never used to determine cA,
so the CVE fix is preserved.
Fixes#11006
Signed-off-by: v1rtu3x <149050962+v1rtu3x@users.noreply.github.com>
An empty AuthorityKeyIdentifier SEQUENCE must parse. A [0] tag without
a length must still be rejected; that case already passed before the
fix and guards against loosening the check too much.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Christopher Müller <chris@mechatronikmonkey.de>
All fields of AuthorityKeyIdentifier are OPTIONAL, so an empty SEQUENCE
(30 00) is syntactically valid. It was rejected with
MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_OUT_OF_DATA,
because mbedtls_asn1_get_tag() reports OUT_OF_DATA rather than
UNEXPECTED_TAG when there is nothing left to parse.
Check for the empty sequence explicitly instead of treating OUT_OF_DATA
as an absent keyIdentifier: OUT_OF_DATA is also returned for a [0] tag
with a missing or truncated length, which must still be rejected.
Fixes#10253.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Christopher Müller <chris@mechatronikmonkey.de>
- mbedtls_endpoint_sanity() is only used for TLS 1.2 tests, where RSA
signatures are limited to PKCS#1 v1.5. Moreover the test does not
perform a full handshake, so only being able to hold an RSA public key
is required here: PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY.
- move_handshake_to_state() is used for both TLS 1.2 and TLS 1.3 tests
and the RSA capabilities it needs depend on the handshake state being
reached, so the RSA dependency is set on test data instead.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
- Mbed TLS only implements TLS 1.2 and DTLS 1.2 (not 1.0/1.1) and there
RSA signatures are limited to PKCS#1 v1.5, so replace
PSA_HAVE_ALG_SOME_RSA_SIGN with PSA_HAVE_ALG_RSA_PKCS1V15_SIGN.
- move_handshake_to_state() sets options.pk_alg = MBEDTLS_PK_RSA, so some
minimal support for RSA keys is always needed: at least an RSA public
key. Stricter requirements only apply depending on the protocol version
(TLS 1.2 vs 1.3) and on the handshake state reached by the test (ex:
initial phase vs ending phase), so they are set per test case.
- Test cases already requiring MBEDTLS_X509_RSASSA_PSS_SUPPORT don't need
PSA_WANT_ALG_RSA_PSS too, since the former depends on the latter.
- Add a comment to the handshake_psk_cipher test cases to explain why a
test which is ideally about PSK has requirements on RSA and EC keys.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
PKCS7 supports ECC as well so the test function should not be guarded or
limited to RSA build symbols. Those guards are now set on the test data
as required by each test itself. This allows for test extension to also
include ECC testing (not present now).
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
pkcs7_verify() is about to lose its blanket RSA guard, so each test case
must declare what it actually needs:
- cases that really validate an RSA signature require
PSA_HAVE_ALG_RSA_PKCS1V15_VERIFY. This includes the cases which used
to pass accidentally because the certificate is invalid and the code
never gets to verify the signature: using the same dependency as the
valid cases is more uniform;
- cases which are expected to fail before reaching signature
verification only require PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
- Tests that only parse a certificate/CRL/CSR without verifying any
signature only need to be able to hold an RSA public key, so replace
PSA_HAVE_ALG_SOME_RSA_VERIFY with PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY.
PSA_HAVE_ALG_SOME_RSA_VERIFY is kept in x509_verify tests, which do
verify signatures.
- x509_parse_rsassa_pss_params tests don't need any explicit RSA
dependency: the test function already depends on
MBEDTLS_X509_RSASSA_PSS_SUPPORT which itself depends on
PSA_WANT_KEY_TYPE_RSA_KEY_PAIR_BASIC, i.e. something "stronger" than
PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
MBEDTLS_X509_RSASSA_PSS_SUPPORT depends on PSA_WANT_ALG_RSA_PSS, so add
the corresponding reverse dependency and include PSA_WANT_ALG_RSA_PSS in
the 'pkalgs' ComplementaryDomain in order to also test builds where
RSA-PSS is disabled.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Cover the serialized out_cid length with the same construction as the
in_cid one, and rename the existing case to IN_CID accordingly. Give
the client and server sentinel CIDs different lengths so the two
fields can be told apart in the serialized data. Skip the CID cases
under configurations of MBEDTLS_SSL_CID_IN_LEN_MAX and
MBEDTLS_SSL_CID_OUT_LEN_MAX that the test does not support.
Signed-off-by: Naveed <naveed@bugqore.com>
The previous approach documented the in_cid_len > sizeof(in_cid) cap
as untestable, since the overflowing memcpy() lands inside the
transform structure where sanitizers cannot see it. It can be guarded
without a sanitizer: grow the in_cid field in the loaded data (keep
its bytes, pad to MBEDTLS_SSL_CID_IN_LEN_MAX + 1) and append the rest
of the serialized data untouched, so the in-buffer bounds check passes
and the cap is what must reject the length. Without the cap the
remaining data parses correctly aligned and the load succeeds, so the
test catches a regression by the return value alone.
Signed-off-by: Naveed <naveed@bugqore.com>
With the loaded data cut right after the in_cid bytes, even the
pristine in_cid length tripped the (end - p) < in_cid_len + 1u bounds
check, since the out_cid length byte it accounts for was missing: the
truncation, not the corruption, was what got rejected. Keep the
out_cid length byte in the loaded data, so the pristine length passes
the check and only the corrupted length trips it. Also document why
this pre-existing check is the only one in the in_cid path that a
regression test can guard: the in_cid_len > sizeof(in_cid) cap
protects the memcpy() destination, and without it the overflow lands
in the out_cid field inside the transform structure, where sanitizers
cannot see it.
Signed-off-by: Naveed <naveed@bugqore.com>
The corrupted in_cid length exercised the pre-existing size-cap check,
not the bounds check: the in_cid field is not the last one serialized,
and the MBEDTLS_SSL_CID_IN_LEN_MAX cap is smaller than the size of the
fields that follow it, so no corrupted length could reach past the end
of the full buffer, and reverting the bounds check did not change the
test's outcome. Truncate the loaded data right after the in_cid bytes,
load from a tightly allocated copy, and corrupt the length to one byte
past that end, so that reverting the bounds check now trips ASan with
an out-of-bounds read in the memcpy(), like the ALPN case.
Signed-off-by: Naveed <naveed@bugqore.com>
Load the serialized context once before corrupting it, to check the
data is well-formed to begin with. Shorten the second ALPN protocol so
the corrupted length overruns the serialized data by exactly one byte,
and assert that property at runtime. Document that the corrupted load
usually fails even without the bounds check, so the regression is only
caught when the suite runs under ASan or Valgrind.
Signed-off-by: Naveed <naveed@bugqore.com>
Fold ssl_context_load_rejects_oob_cid_length and
ssl_context_load_rejects_oob_alpn_length into a single parameterized
test function, since they shared most of their code.
Signed-off-by: Naveed <naveed@bugqore.com>
The serialized ALPN length was passed to memcmp() against each configured protocol without checking it against the remaining serialized data, so a malformed context could read past the end of the buffer. Bound it before the comparison, like the adjacent CID fields.
Signed-off-by: Naveed <naveed@bugqore.com>
OAEP is for RSA encryption and therefore is not the correct check when
we want to test for signatures with PSS.
Additionally, we can use RSA PSS when we only have public key support
(not key pairs) so check for PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY (which is
auto-enabled when we have key pairs enabled anyway).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This is useful for debugging purposes because, for example, the user
only want to build a specific suite and/or only run it instead of
building and testing everything for all the jobs.
For this scope the custom command can be a bash script that's executed
instead of 'make' + 'make test'.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Generated tf-psa-crypto private includes path in
'crypto_builtin_primitives.h' were wrong. For example the output for
'blake2.h' was:
"libtestdriver1/tf-psa-crypto/include/tf-psa-crypto/private/blake2.h"
whereas it should have been
"libtestdriver1/tf-psa-crypto/drivers/builtin/include/tf-psa-crypto/private/blake2.h"
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
