summaryrefslogtreecommitdiff
path: root/src/lib/libc/stdlib/reallocarray.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2026-04-03Mop up mac_packet.jsing4-15/+8
This is a left over from when we accepted SSLv2 ClientHello messages. ok kenjiro@
2026-04-01Adjust depth check to match change in verifier.jsing1-2/+2
2026-04-01Restore the previous behaviour with maximum verification depth.jsing1-7/+7
The maximum depth is not expected to include the leaf certificate - restore the decrement prior to checking, which means the previous behaviour is retained for the callback depth and the maximum depth. Reduce the maximum depth by one in order to avoid the overwrite that could previously occur. Thanks to anton@ for flagging the rust-openssl failure in regress. ok tb@
2026-03-31Fix an off-by-one error in the X.509 verifier depth checking.jsing1-6/+11
In x509_verify_build_chains(), ensure that we check the current depth against max_depth prior to turning it into a legacy-style depth index. Additionally, add a guard to x509_verify_chain_append() so that we avoid exceeding the maximum certs per chain, even if we fail to handle this correctly elsewhere. Also prevent the legacy callback from being able to override the maximum verification depth. The current off-by-one allows for a 4 byte overwrite to occur on heap allocated memory - this will likely trigger a crash on OpenBSD (but may go unnoticed elsewhere). This is only reachable if a TLS client is talking to a malicious server or if a TLS server has client certificate verification enabled - in both cases the verification depth also needs to be set to the maximum allowed value of 32. It is worth noting that many TLS clients/servers set the maximum verification depth to a value that is much less than the default. A libtls client or server uses a default depth of 6 and is not impacted in this configuration. Thanks to Calif.io in collaboration with Claude and Anthropic Research, for reporting the issue. ok tb@
2026-03-31Add additional X.509 verifier test cases.jsing2-2/+28
The second case (14b) currently triggers a bug in the new verifier.
2026-03-31Run new test certificate bundles through Go's verifier.jsing1-0/+2
2026-03-31Add additional certificate test bundles.jsing4-0/+1450
2026-03-31Generate two additional certificate test scenarios which have deep chains.jsing1-0/+16
2026-03-30libssl regress: adjust golden numbers for RSASSA-PSStb2-39/+44
Add the three RSASSA-PSS SignatureScheme 0x080b, 0x080a, 0x0809 in the appropriate spots in (components of) the ClientHello and adjust various length octets by adding 6.
2026-03-30libssl: announce support for RSASSA-PSS signature schemestb1-1/+7
Announce the signature schemes for RSASSA-PSS with pubkey OID RSASSA-PSS between RSASSA-PSS with pubkey OID rsaEncryption and RSASSA-PKCS1-v1_5. This is the last step in the everlasting saga for making these signature schemes and certificates with RSASSA-PSS OID work. Fortunately, these are rarely used since they are extremely complex and inefficient also due to the large size of the parameters. This addresses bug reports by Steffen Ullrich and Tom Lane. Tested by bluhm. ok djm jsing kenjiro
2026-03-30ssl_sigalg_pkey_ok: allow RSASSA-PSS with pubkey OID RSASSA-PSStb1-5/+6
This fixes a long-standing logic error that hasn't been noticed because we never announced the rsa_pss_pss_sha{256,384,512} SignatureScheme. The EVP_PKEY_id() of a RSA-PSS pubkey is EVP_PKEY_RSA_PSS, not EVP_PKEY_RSA. Thanks to beck for helping me figure out how to fix this correctly. It drove me nuts for a very long time. Problem also noticed by Tom Lane due to some PostgreSQL regress failures. ok djm jsing kenjiro
2026-03-30ssl_sigalgs: whitespace tweaktb1-1/+2
2026-03-29ML-KEM: ensure that key_768 is only dereferenced with 768-bit keystb1-3/+7
This looks like a NULL dereference that should crash, but for some reason it doesn't, even with -O0 with all compilers i tried. At the very least it may result in compilers deducing that key_768 != NULL and lead to incorrect optimizations. ok claudio jsing kenjiro miod
2026-03-29Add missing include path required to reach newly added crypto_assembly.hanton1-2/+3
include.
2026-03-28Include crypto_assembly.h instead of manually ensuring _CET_ENDBR exists.jsing6-36/+12
ok kenjiro@ tb@