[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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.