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>
(cherry picked from commit 62dd8a556c01cc289d4fb3f19352a78ede90dac2)
Backport of f79eac885dec294d6e441bada15be1605dcb75b0. Adapt the check and tests to the 3.6 OID parser.
Refs Mbed-TLS/mbedtls#10911.
Signed-off-by: subotac <73706465+subotac@users.noreply.github.com>
Backport the ssl_context_load_rejects_oob_length test function from
development in its final form, with cases for the serialized in_cid,
out_cid and ALPN lengths.
mbedtls_test_ssl_dtls_join_endpoints() and
mbedtls_test_ssl_perform_connection() do not exist on this branch, so
set up the DTLS endpoints and run the handshake with the helpers that
do: mbedtls_test_ssl_endpoint_init() with message queues,
mbedtls_test_mock_socket_connect() and
mbedtls_test_move_handshake_to_state(). Exchange application data
explicitly before saving the context, as
mbedtls_test_ssl_perform_connection() does on development: the server
keeps its handshake structure until then, and
mbedtls_ssl_context_save() refuses to run while it exists.
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>
Previous wording only named the four low-level update() functions
directly touched by the fix. mpg pointed out a normal user calling
mbedtls_md_update(), psa_hash_compare(), or any of the one-shot
wrappers (mbedtls_md5(), mbedtls_sha256(), psa_hash_compute(), etc.)
has no way to tell from that wording whether they are affected, and
that SHA-224 should be listed explicitly even though it shares
mbedtls_sha256_update() under the hood, since that implementation
detail should not be something a ChangeLog reader needs to already
know.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
Per mpg's review, MD5, SHA-1 and RIPEMD-160 have the exact same bug as
SHA-256: mbedtls_*_update() truncates ilen to its low 32 bits before
adding it to ctx->total[0], and the overflow check right after only
catches the single wraparound of that 32-bit addition -- neither step
folds in bits 32 and up of ilen itself when a single update() call is
passed >= 2^32 bytes on a 64-bit platform.
SHA-512 does not have this bug (confirmed by TimothyPMann and
independently by me): it tracks its 128-bit byte count in two
uint64_t words, so ilen (a 64-bit size_t at most) can never overflow
the low word before the carry-in step even runs.
Applied the identical fix to all three: fold ilen >> 32 into total[1],
guarded on SIZE_MAX so 32-bit platforms are unaffected.
Verified live with the same method as the SHA-256 fix: hashed a real
4GiB + 64 byte file with mbedtls_md5_update()/sha1_update()/
ripemd160_update() in a single call and compared against md5sum(1),
sha1sum(1), and `openssl dgst -rmd160`.
algorithm before fix (wrong) after fix (matches reference tool)
MD5 0e8b3fdad1980e2c4e66ef714abc3f0c 8b647773014d9f640da9887274f444cd
SHA-1 b190a761fceaafdc19b62cbcc729ec22b02e7d0c 703fe5b4441eb203af67ed4fbc20263d44bc5f5c
RIPEMD-160 68956d1517f2ebcef4761d2c0fddf11331a1e6b6 d14d7e80c32ddc603c677151bfd59fd8cf867c42
Also reworded the ChangeLog entry per feedback to cover all four
functions concisely instead of describing the SHA-256 internals in
detail.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
mbedtls_sha256_update() tracks the running byte count in a 64-bit
counter split across ctx->total[0]/[1] (32 bits each), used at
finalization to encode the message length into the padding.
ctx->total[0] += (uint32_t) ilen truncates ilen to its low 32 bits
before adding, and the overflow check right after (ctx->total[0] <
(uint32_t) ilen) only detects the single wraparound of that 32-bit
addition. Neither step ever looks at bits 32 and up of ilen itself.
So when a single update() call is passed >= 2^32 bytes on a 64-bit
platform (size_t wider than 32 bits), every byte is correctly hashed
into the message, but the length folded into the final padding block
is wrong by a multiple of 2^32 bytes, producing an incorrect digest
despite no error being returned.
Fold ilen>>32 into total[1] directly, guarded on SIZE_MAX so 32-bit
platforms (where ilen cannot exceed 2^32-1 and the shift would be
UB-adjacent) are unaffected.
Verified live: generated a 4GiB+64 byte random file, hashed it with
mbedtls_sha256_update() in a single call both before and after this
fix, and compared against sha256sum of the same file.
- before: 803ab176fbafaf3cf345cbe22e2a35715c3ae8f7fbf241a00677d4d733db0214 (wrong)
- after: 21a1f671cd9797227f341a243fed82c8fe95a769a58a6f3965e958f047e969d6 (matches sha256sum)
Also re-verified normal-sized inputs (empty string, "abc") against
known SHA-256 vectors, and that a two-call split of a 100-byte input
still agrees with a single whole-buffer call.
Fixes#10964.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
Backport the final approved implementation from Mbed-TLS/TF-PSA-Crypto#843
to mbedtls-3.6.
Enable the existing Linux getrandom syscall path when sys/syscall.h
is available and defines SYS_getrandom. Preserve the existing
glibc/Midipix detection and runtime ENOSYS fallback.
Apply the platform change to library/entropy_poll.c in this branch.
Signed-off-by: Ning Xia <hi@nosec.me>
