[openssl/openssl] 97f6b6: Reject oversized inputs in ASN1_mbstring_ncopy()
"'Igor Ustinov' via openssl-commits" <[email protected]>
| Newsgroups | gmane.comp.encryption.openssl.cvs |
|---|---|
| Message-ID | <openssl/openssl/push/refs/heads/master/[email protected]> |
Branch: refs/heads/master
Home: https://github.com/openssl/openssl
Commit: 97f6b621f7af2c4c4e162c75045a6e12a8fdf8d9
https://github.com/openssl/openssl/commit/97f6b621f7af2c4c4e162c75045a6e12a8fdf8d9
Author: Viktor Dukhovni <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/asn1/a_mbstr.c
Log Message:
-----------
Reject oversized inputs in ASN1_mbstring_ncopy()
In ASN1_mbstring_ncopy() the destination size for BMPSTRING and
UNIVERSALSTRING output was computed by a signed left shift on an
int:
outlen = nchar << 1; /* MBSTRING_BMP */
outlen = nchar << 2; /* MBSTRING_UNIV */
For nchar large enough the result is not representable in int. In
the worst case (nchar == 0x40000000) nchar << 2 wraps to zero,
OPENSSL_malloc(1) is called, and traverse_string() then writes
4*nchar bytes into the one-byte allocation: a heap buffer
overflow. The MBSTRING_UTF8 path computes outlen by summing
per-character byte counts in out_utf8(), and that sum can overflow
the same int under similarly large inputs.
Neither path is reachable from code that processes X.509
certificates through the DIRSTRING_TYPE mask used by
ASN1_STRING_set_by_NID(): UNIVERSALSTRING is absent from that
mask, and the UTF-8 sum requires inputs on the order of half a
gigabyte. Reaching them needs an application that calls
ASN1_mbstring_copy()/ASN1_mbstring_ncopy() directly, or registers
a custom NID via ASN1_STRING_TABLE_add(), with an oversized
attacker-controlled input.
Add range checks before each shift and in out_utf8(), raising
ASN1_R_STRING_TOO_LONG at the point of detection. Move the
existing ASN1_R_INVALID_UTF8STRING raise into out_utf8() too so
the two failure modes report distinct codes; the MBSTRING_UTF8
caller is left with cleanup only and now frees dest on error,
matching the BMP/UNIV branches.
Fixes CVE-2026-7383
Reviewed-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Eugene Syromiatnikov <[email protected]>
MergeDate: Mon Jun 8 14:02:18 2026
Commit: 51d1800e95283a8beec85152e35e3634dab8dd82
https://github.com/openssl/openssl/commit/51d1800e95283a8beec85152e35e3634dab8dd82
Author: Nikola Pajkovsky <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/cms/cms_pwri.c
Log Message:
-----------
cms: kek_unwrap_key: Fix out-of-bounds read in check-byte validation
the check-byte test in kek_unwrap_key() reads tmp[1] through tmp[6]
unconditionally, so the decrypted buffer must hold at least seven
octets. The pre-decryption size check enforces inlen >= 2 * blocklen,
which yields the required seven octets only when blocklen >= 4. For
a KEK cipher with a smaller block size, inlen can be as small as
2 * blocklen and the check-byte read overruns the inlen-sized tmp
allocation.
Reject blocklen < 4 in the early sanity check. All block ciphers
appropriate for CMS PasswordRecipientInfo key wrapping have a block
size of at least 8 octets (DES/3DES = 8, AES = 16), so this only
forbids ciphers that would not be valid KEK choices anyway, and the
existing inlen >= 2 * blocklen check then guarantees the seven-octet
lower bound the check-byte test relies on.
Fixes CVE-2026-9076
Signed-off-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Daniel Kubec <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:06:36 2026
Commit: 2f789ca4f2bbbd57a821c08eabee6d193a03bf24
https://github.com/openssl/openssl/commit/2f789ca4f2bbbd57a821c08eabee6d193a03bf24
Author: Nikola Pajkovsky <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M test/cmsapitest.c
M test/recipes/80-test_cmsapi.t
A test/recipes/80-test_cmsapi_data/cms_pwri_kek_oob.der
Log Message:
-----------
cms: kek_unwrap_key: test for fix out-of-bounds read in check-byte validation
added EnvelopedData blob with a PasswordRecipientInfo using
id-alg-PWRI-KEK and an AES-128-CFB key encryption cipher. CFB's 1-byte
effective block size let the inlen >= 2 * blocklen guard in
kek_unwrap_key() accept a wrapped key shorter than the seven octets
the check-byte test reads from tmp[1..6]; the encryptedKey OCTET
STRING here is only two bytes.
Signed-off-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Daniel Kubec <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:06:38 2026
Commit: fcb23806047f5afbe55d5d601a527fc24bf7ca2c
https://github.com/openssl/openssl/commit/fcb23806047f5afbe55d5d601a527fc24bf7ca2c
Author: Viktor Dukhovni <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/asn1/tasn_dec.c
Log Message:
-----------
Avoid length truncation in ASN1_STRING_set
The ASN1_STRING_set() function takes an `int` length, make sure the
argument is not inadvertently truncated when it is called from
asn1_ex_c2i().
Fixes CVE-2026-34180
Reviewed-by: Nikola Pajkovsky <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:13:56 2026
Commit: 5a0230b6cc95a576b0c2b7b5b2ba7c74232e7b7c
https://github.com/openssl/openssl/commit/5a0230b6cc95a576b0c2b7b5b2ba7c74232e7b7c
Author: Alicja Kario <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/pkcs12/p12_mutl.c
M test/recipes/80-test_pkcs12.t
A test/recipes/80-test_pkcs12_data/pbmac1_256_256.bad-key-len.p12
A test/recipes/80-test_pkcs12_data/pbmac1_256_256.good-shorter-key-len.p12
Log Message:
-----------
pkcs12: verify that the pbmac1 key length is safe
Short mac keys (as short as 1 byte) can be used to probe the
system under attack to accept a PKCS#12 file created by an attacker
even if the attacker doesn't know the password used for MAC protection.
Fixes CVE-2026-34181
(also update the reference to the PBMAC1 PKCS#12 RFC)
Signed-off-by: Alicja Kario <[email protected]>
Reviewed-by: Dmitry Belyavskiy <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:18:59 2026
Commit: 206faade8b3872d265524e56583cfc05ac001da5
https://github.com/openssl/openssl/commit/206faade8b3872d265524e56583cfc05ac001da5
Author: Neil Horman <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/cms/cms_enc.c
Log Message:
-----------
Reject potentially forged encrypted CMS AuthEnvelopedData messages
1. Adjust ossl_cms_EncryptedContent_init_bio to not accept non-AEAD
ciphers.
If a forged CMS message with AuthEnvelopedData is received with
a non-AEAD cipher specified, we silently accept that and decrypt
the message, skipping any authentication, which violates RFC 5083.
We also add checks to ensure we fail if we try to encrypt
AuthEnvelopedData without using an AEAD cipher.
2. Ensure that tag lengths on cms AEAD data is the recommended size.
RFC 5084 recommends that mac tags be at least 12 bytes for AES-GCM
and 4 bytes for AES-CCM on AuthEnvelopedData. As this code is not
algorith-specific we add a check for a minimal size and just use the
lower limit which is sufficient to prevent this attack.
Without this check, its possible to set the tag length to 1 and within
256 guesses, forge a CMS message.
Fixes CVE-2026-34182
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:27:02 2026
Commit: d49444fa987f01e48af72d51cbec6b10a35ae784
https://github.com/openssl/openssl/commit/d49444fa987f01e48af72d51cbec6b10a35ae784
Author: Neil Horman <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M test/cmsapitest.c
Log Message:
-----------
Add tests for CVE-2026-34182
Test to ensure that for a given CMS message:
1) We do not allow the creation of a CMS message containing
AuthEnvelopedData with a non-AEAD cipher.
2) We do not accept a message containing AuthEnvelopedData with a
non-AEAD cipher specified in the AlgorithmIdentifier.
3) We do not allow tag lengths less that 4 bytes.
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:27:03 2026
Commit: 9bedb613191f2d86def2be626b72f239daf81808
https://github.com/openssl/openssl/commit/9bedb613191f2d86def2be626b72f239daf81808
Author: Alexandr Nedvedicky <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M include/internal/quic_cfq.h
M include/internal/quic_channel.h
M include/internal/quic_fifd.h
M ssl/quic/quic_cfq.c
M ssl/quic/quic_channel.c
M ssl/quic/quic_channel_local.h
M ssl/quic/quic_fifd.c
M ssl/quic/quic_rx_depack.c
M ssl/quic/quic_txp.c
Log Message:
-----------
QUIC stack must limit the number of PATH_CHALLENGE frames processed in RX
Currently local QUIC stack allocates PATH_RESPONSE frame for every
PATH_CHALLENGE frame it receives in single packet from its remote peer.
The memory with PATH_RESPONSE frame is released after local QUIC stack
receives an ACK which confirms reception of PATH_RESPONSE by remote peer.
This gives remote peer too much control over memory resources local
QUIC stack may consume.
Quoting RFC 9000 section 9.2.1:
...an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet.
Limiting the number of PATCH_CHALLENGE frames to 1 per QUIC packet received
helps to reduce heap memory overhead required to process PATH_CHALLENGE
frame.
Currently QUIC ACKM (ACK-manager) keeps all frames in retransmission
buffer until ACK is received. It can be changed such frames which
don't need to be ACKed don't need to be kept in retrans buffer,
those can be released right after transmission.
Fixes CVE-2026-34183
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:35:20 2026
Commit: 68ef88913e321bdb47eee88118ceba18ed2388cd
https://github.com/openssl/openssl/commit/68ef88913e321bdb47eee88118ceba18ed2388cd
Author: Alexandr Nedvedicky <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M include/internal/quic_channel.h
M ssl/quic/quic_channel.c
M ssl/quic/quic_channel_local.h
M ssl/quic/quic_rx_depack.c
M test/radix/quic_tests.c
Log Message:
-----------
Add test for path challenge flood mitigation
client injects 16 path challenge frames. Those are received
by server. Only one challenge frame of 16 received triggers
path challenge response. Remaining challenge frames are
discrded/ignored.
Test introduces two counters to channel object:
- path_challenge_rx which is bumped for every patch challenge
frame received
- path_response_tx which is bumped for every path response
frame transmitted
Succesuful test verifies server receives 16 path challenge frames,
but sends just one path response frmae as response.
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:35:21 2026
Commit: 58633b658fe74095c8cdde191e4ce1bf94f8c5f9
https://github.com/openssl/openssl/commit/58633b658fe74095c8cdde191e4ce1bf94f8c5f9
Author: Daniel Kubec <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/x509/x509_vfy.c
Log Message:
-----------
Fix Double-free When Checking OCSP Stapled Response
If OCSP stapling is enabled and the TLS client connects to a malicious server,
a crafted OCSP stapled response can trigger a double free in the TLS client
when the stapled response is checked.
The OCSP stapling is not enabled by default. Reliable code execution
through a double-free is technically complex and highly environment-dependent
but the Denial of Service impact is straightforward to achieve, warranting
Moderate severity.
Fixes CVE-2026-35188
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:44:58 2026
Commit: 5097ec4dae239112498abb722e255ea60ef7ac48
https://github.com/openssl/openssl/commit/5097ec4dae239112498abb722e255ea60ef7ac48
Author: Alexandr Nedvedicky <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M ssl/quic/quic_port.c
Log Message:
-----------
Fix NULL dereference in QUIC address validation
QUIC server crashes when address validation (RFC 9000, Section 8.1)
is disabled and client sends initial packet with invalid token.
Issue reported and fix submitted by Sunwoo Lee (KENTECH),
Hyuk Lim (KENTECH) and Seunghyun Yoon (KENTECH)
Fixes CVE-2026-42764
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 14:50:48 2026
Commit: a9af3442290e8a04706a3cd5f284ffd5b486e3f6
https://github.com/openssl/openssl/commit/a9af3442290e8a04706a3cd5f284ffd5b486e3f6
Author: Daniel Kubec <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/x509/x509_vfy.c
Log Message:
-----------
Fix NULL Dereference in Certificate Verification with OCSP Checking
When performing OCSP response checking for certificates in the verification
chain, the code always tries to access the next certificate as the issuer.
There is a check for a self-signed certificate. However with the partial
chain verification enabled when the chain does not have a self-signed trusted
anchor, the issuer will be NULL for the last certificate in the chain. A NULL
pointer dereference then happens.
This issue affects only applications which enable both OCSP verification
of the certificate chain (X509_V_FLAG_OCSP_RESP_CHECK_ALL) and partial
chain verification (X509_V_FLAG_PARTIAL_CHAIN) in the certificate
verification. Both flags are disabled by default. For that reason, we have
assigned Low severity to the issue.
Fixes CVE-2026-42765
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 18:55:29 2026
Commit: 74245170b5a64b234ac4af27c86a25ec251c8b2a
https://github.com/openssl/openssl/commit/74245170b5a64b234ac4af27c86a25ec251c8b2a
Author: Igor Ustinov <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/cms/cms_pwri.c
Log Message:
-----------
Fix potential NULL dereference processing CMS PasswordRecipientInfo
Avoid NULL dereferencing when keyDerivationAlgorithm is absent
in CMS PasswordRecipientInfo.
Fixes CVE-2026-42766
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 18:57:52 2026
Commit: f04d65692dd8109be9f387ce2ddd9fb1ab612b6b
https://github.com/openssl/openssl/commit/f04d65692dd8109be9f387ce2ddd9fb1ab612b6b
Author: Igor Ustinov <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
A test/cms-msg/make_missing_kdf_der.py
A test/cms-msg/missing-kdf.der
M test/recipes/80-test_cms.t
Log Message:
-----------
Test for CVE-2026-42766
The script make_missing_kdf_der.py was developed by Mayank Jangid
and Kushal Khemka.
Co-Authored-by: Mayank Jangid <[email protected]>
Co-Authored-by: Kushal Khemka <[email protected]>
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 18:57:53 2026
Commit: d5030cdf32d6cd27bd964a0cb7aed2b7cb713369
https://github.com/openssl/openssl/commit/d5030cdf32d6cd27bd964a0cb7aed2b7cb713369
Author: Dmitry Belyavskiy <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/cms/cms_env.c
M crypto/pkcs7/pk7_doit.c
M doc/man3/CMS_decrypt.pod
M doc/man3/PKCS7_decrypt.pod
Log Message:
-----------
Enforce implicit rejection for CMS/PKCS#7 decryption
Drop the disablement of the implicit rejection for RSA PKCS#1 v1.5
decryption.
Fixes CVE-2026-42768
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Alicja Kario <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 19:49:19 2026
Commit: c2765d53c2649b56bc1ca1bb799e42002953056a
https://github.com/openssl/openssl/commit/c2765d53c2649b56bc1ca1bb799e42002953056a
Author: Bob Beck <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/cmp/cmp_genm.c
Log Message:
-----------
Use the correct issuer when validating rootCAKeyUpdate
This correctly uses the existing root, and not the same certificate
as the root of the chain to validate.
While we are here, we also turn on self signed certificate signature
checking as this case is actually bringing in trust anchors as
self signed certs, and fix a possible NULL deref.
Fixes CVE-2026-42769
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 19:54:01 2026
Commit: 0f3fab2eccc7c3417093a8243dd15d95b6cb472d
https://github.com/openssl/openssl/commit/0f3fab2eccc7c3417093a8243dd15d95b6cb472d
Author: Norbert Pocs <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M providers/implementations/exchange/dh_exch.c
Log Message:
-----------
Match the local q DHX parameter against the peer's q
As FFC/DH peer public key validation uses the peer's q value instead
of checking against the local q, we must also check that these
q values match when setting the peer's public key.
Fixes CVE-2026-42770
Signed-off-by: Norbert Pocs <[email protected]>
Reviewed-by: Viktor Dukhovni <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 19:56:27 2026
Commit: b3a555a0a7aa0028887149f6f973af89a4937bea
https://github.com/openssl/openssl/commit/b3a555a0a7aa0028887149f6f973af89a4937bea
Author: Bob Beck <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/x509/x509_vpm.c
Log Message:
-----------
Fix length miscalculation in validate_email
We incorrectly used the length of the domain part for the local part
when validating e-mail for X509_VERIFY_PARAM_set1_email().
Fixes CVE-2026-42771
Reviewed-by: Viktor Dukhovni <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 19:59:28 2026
Commit: 5f489043b662fed32fbf7eb7442c479568eb43fd
https://github.com/openssl/openssl/commit/5f489043b662fed32fbf7eb7442c479568eb43fd
Author: Bob Beck <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M test/verify_extra_test.c
Log Message:
-----------
Add further unit tests for e-mail validation
Ensure we correctly catch misformed things.
Reviewed-by: Viktor Dukhovni <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 19:59:29 2026
Commit: f87f0b6a8e04bcdeb98afc82b0da06a2d537f399
https://github.com/openssl/openssl/commit/f87f0b6a8e04bcdeb98afc82b0da06a2d537f399
Author: Viktor Dukhovni <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M providers/implementations/ciphers/cipher_aes_ocb.c
M test/evp_extra_test.c
Log Message:
-----------
Apply the buffered IV on the AES-OCB EVP_Cipher() path
aes_ocb_cipher(), the OCB provider's OSSL_FUNC_CIPHER_CIPHER slot,
processed input without flushing the buffered IV into the OCB
context. Effective nonce was 0 regardless of the caller's IV;
EVP_*Final_ex() then emitted a tag depending only on (key, iv).
This gave (key, nonce) reuse and single-query universal forgery on
the EVP_Cipher() path.
Apply update_iv() at the head of aes_ocb_cipher() to mirror the
streaming handler. The matching GCM one-shot does this already.
Add a cross-driver round-trip test for AES-{GCM,CCM,OCB} and
ChaCha20-Poly1305 in test/evp_extra_test.c. Each cipher is
exercised with and without AAD; the no-AAD case is needed because
any prior EVP_CipherUpdate(NULL, aad, ...) routes through the
streaming handler and applies the IV itself, masking the bug.
Fixes CVE-2026-45445
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 20:02:00 2026
Commit: 609bcb24866d64f1fc49d38b852edbb39057d721
https://github.com/openssl/openssl/commit/609bcb24866d64f1fc49d38b852edbb39057d721
Author: Dmitry Belyavskiy <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M providers/implementations/ciphers/cipher_aes_gcm_siv_hw.c
M providers/implementations/ciphers/cipher_aes_siv.c
M test/evp_extra_test.c
Log Message:
-----------
Fix handling of empty-ciphertext messages in AES-GCM-SIV and AES-SIV
AES-GCM-SIV: EVP_DecryptFinal_ex Accepts All-Zero Tag for Empty-Ciphertext
Messages.
AES-SIV: EVP_DecryptUpdate_ex Accepts All-Zero Tag for Empty-Ciphertext
Messages on context reuse.
Fixes CVE-2026-45446
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 20:12:25 2026
Commit: f4129fbe3cde786d363510069fe297234f99be8f
https://github.com/openssl/openssl/commit/f4129fbe3cde786d363510069fe297234f99be8f
Author: Igor Ustinov <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/pkcs7/pk7_smime.c
Log Message:
-----------
Fix possible use-after-free in OpenSSL PKCS7_verify()
Fixes CVE-2026-45447
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 20:22:50 2026
Commit: 463b444cb16474fdcf2f5ce66227afe2a215f38c
https://github.com/openssl/openssl/commit/463b444cb16474fdcf2f5ce66227afe2a215f38c
Author: Igor Ustinov <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M test/recipes/80-test_cms.t
A test/smime-eml/pkcs7-empty-digest-set.eml
Log Message:
-----------
Test for CVE-2026-45447 (UAF in PKCS7_verify)
The test data were created with a tool developed by
Thai Duong <[email protected]>.
Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 20:22:52 2026
Commit: 11df4e2ae04fe3f3207aa79b461b6ed90e5f6bce
https://github.com/openssl/openssl/commit/11df4e2ae04fe3f3207aa79b461b6ed90e5f6bce
Author: Igor Ustinov <[email protected]>
Date: 2026-06-11 (Thu, 11 Jun 2026)
Changed paths:
M crypto/crmf/crmf_lib.c
Log Message:
-----------
Fix potential NULL dereference in OSSL_CRMF_ENCRYPTEDVALUE_decrypt()
Check that 'parameter' != NULL before dereferencing in
OSSL_CRMF_ENCRYPTEDVALUE_decrypt().
Fixes CVE-2026-42767
Reviewed-by: Neil Horman <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
MergeDate: Mon Jun 8 20:38:27 2026
Compare: https://github.com/openssl/openssl/compare/cb005ceaaf1f...11df4e2ae04f
To unsubscribe from these emails, change your notification settings at https://github.com/openssl/openssl/settings/notifications
--
You received this message because you are subscribed to the Google Groups "openssl-commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-commits/openssl/openssl/push/refs/heads/master/cb005c-11df4e%40github.com.