[openssl/openssl] 7b84de: Add test for CVE-2026-63076

  Branch: refs/heads/master
  Home:   https://github.com/openssl/openssl
  Commit: 7b84dec93fc02b8e97a7b620c6195cbaee9e62d9
      https://github.com/openssl/openssl/commit/7b84dec93fc02b8e97a7b620c6195cbaee9e62d9
  Author: Daniel Kubec <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M test/cmp_protect_test.c

  Log Message:
  -----------
  Add test for CVE-2026-63076

Assisted-by: Claude:claude-fable-5
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Merge-date: Sat Aug 22 06:10:00 2026


  Commit: 022a99e2b50cccb94b7d3efb7080077c28276272
      https://github.com/openssl/openssl/commit/022a99e2b50cccb94b7d3efb7080077c28276272
  Author: Daniel Kubec <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M crypto/cmp/cmp_protect.c

  Log Message:
  -----------
  Fix Remote NULL deref in ossl_cmp_calc_protection() via crafted protectionAlg

ossl_cmp_calc_protection() only checked whether the protectionAlg parameter
(ppval) was NULL before treating it as a PBMParameter ASN1_STRING.

X509_ALGOR_get0() does not validate the ASN.1 type of the parameter against what
the caller expects. For id-PasswordBasedMAC, a crafted message can encode the
parameter as a BOOLEAN instead of the expected PBMParameter SEQUENCE. Because
the ASN1_TYPE value union overlays the boolean int on the pointer field, ppval
comes back as a bogus non-NULL pointer (e.g. 0xff).

Fixes CVE-2026-63076

Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Merge-date: Sat Aug 22 06:10:03 2026


  Commit: b758149ceacb622300430afa1e8cd5fa9a0f3a90
      https://github.com/openssl/openssl/commit/b758149ceacb622300430afa1e8cd5fa9a0f3a90
  Author: Neil Horman <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M include/internal/quic_ackm.h
    M ssl/quic/quic_ackm.c
    M ssl/quic/quic_txp.c

  Log Message:
  -----------
  Don't store ACK-only frames in TX history for QUIC.

When QUIC sends an ACK-only frame, there is no expectation that the
peer will ack that ack (i.e. it is itself not ack-eliciting).  However,
our implementation stores these frames in the TX history regardless.  In and
of itself thats ok, but if a malicious client establishes a connection,
and then drives the connection such that ack-only frames are forced from
the peer (i.e. by sending numerous ping frames), and then withholding
any subseqent acks for ack-eliciting data, like legitimate data, said
malicious client can force inappropriate memory growth on the server,
leading to potential DOS attacks.

Don't store any ACK-only frames in the TX history to address this.  Record it in
our TX history so that the send window moves forward appropriately, but for
ack-only frames, immediately remove it, since we don't expect to get an ack for
them anyway.

Initially authored by Opal Wright <[email protected]>

The initial proposal had some shortcommings in which the highest pn
acked value was not accounted for which I have fixed with the assistance
of Claude

Assisted-by: Anthopic Sonnet 5

Fixes CVE-2026-63075

Reviewed-by: Saša Nedvědický <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Merge-date: Mon Aug 24 12:07:51 2026


  Commit: 6a06a6edbfe3ac97b72b2c630e25fcd0e1540251
      https://github.com/openssl/openssl/commit/6a06a6edbfe3ac97b72b2c630e25fcd0e1540251
  Author: Neil Horman <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M test/build.info
    A test/cmp_extracerts_dos_test.c
    M test/recipes/65-test_cmp_msg.t

  Log Message:
  -----------
  Add a test for restricting growth in cmp cert cache

Test to ensure that if certs are rejected we don't add them unboundedly
to the cmp contexts cert cache.

Assisted-by: Claude sonnet 4.6
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Merge-date: Mon Aug 24 12:41:40 2026


  Commit: a6c1091a8feadf0a16851cdda38a85aafe41cb11
      https://github.com/openssl/openssl/commit/a6c1091a8feadf0a16851cdda38a85aafe41cb11
  Author: Neil Horman <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M crypto/cmp/cmp_vfy.c

  Log Message:
  -----------
  Fix unbounded cert cache growth in cmp

If a remote user sends cmp messages to a server with a list of
extraCerts and the message is rejected, the extraCerts from the message
remain in the server contexts untrusted certificate stack.  This exposes
servers with long lived ctx objects to denial of service attacks in
which an attacker sends messages intending to be rejected with a large
list of additional cerificated repeatedly, forcing the server to store
them indefinately.

Fix it by rolling back the added extra certs if the message is rejected,
using the same method we do when the context is configured to not do
caching at all.

Fixes openssl/srt#224

Fixes CVE-2026-63074

Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Merge-date: Mon Aug 24 12:41:41 2026


  Commit: b8e5bb958ee4501a95b424c6f9f457dd013b4d83
      https://github.com/openssl/openssl/commit/b8e5bb958ee4501a95b424c6f9f457dd013b4d83
  Author: Viktor Dukhovni <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M ssl/t1_lib.c
    M test/rpktest.c

  Log Message:
  -----------
  Handle signature_algorithms_cert extension in key-only context

Servers or clients that configure only a private key in
expectation of always negotiating use of RFC7250 raw public keys
failed to handle the "signature_algorithms_cert" extension.

The issue is now resolved and the RPK tests now check that
key-only configurations are robust also when the extension
is sent by the peer.

Key-only configurations are quite uncommon.  As a best practice,
RPK-capable servers and clients pair their private key with a
(possibly self-signed) certificate, enabling fallback to X.509
handshakes with non-RPK peers.

Fixes CVE-2026-14457

Reviewed-by: Eugene Syromiatnikov <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Merge-date: Mon Aug 24 12:48:45 2026


  Commit: 958f6f6040385a88a322673dbb465f7259ebf0f2
      https://github.com/openssl/openssl/commit/958f6f6040385a88a322673dbb465f7259ebf0f2
  Author: Norbert Pocs <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M crypto/cmp/cmp_vfy.c

  Log Message:
  -----------
  CMP unexpected sender DN used as format string in ERR_raise_data()

ossl_cmp_msg_check_update() converts an unexpected CMP response sender DN with
X509_NAME_oneline() and passes that peer-controlled string directly as the
format argument to ERR_raise_data(). Printable percent characters survive the
DN conversion, so a sender such as CN=%s%n reaches vsnprintf() as active format
syntax without matching varargs.

Fixes: CVE-2026-63073

Original patch by: Filipe Casal of Trail of Bits in collaboration with OpenAI

Signed-off-by: Norbert Pocs <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Reviewed-by: Igor Ustinov <[email protected]>
Merge-date: Mon Aug 24 12:53:37 2026


  Commit: a6286cd01801a50aec5fc5b10e7ac73399d160f0
      https://github.com/openssl/openssl/commit/a6286cd01801a50aec5fc5b10e7ac73399d160f0
  Author: Norbert Pocs <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M test/cmp_vfy_test.c

  Log Message:
  -----------
  Add test for CVE-2026-63073

Signed-off-by: Norbert Pocs <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Reviewed-by: Igor Ustinov <[email protected]>
Merge-date: Mon Aug 24 12:53:37 2026


  Commit: 13bcff0ab2f5c55696c92cc6b3480d94f80e8e3b
      https://github.com/openssl/openssl/commit/13bcff0ab2f5c55696c92cc6b3480d94f80e8e3b
  Author: Daniel Kubec <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M crypto/cms/cms_kari.c
    M crypto/cms/cms_kemri.c

  Log Message:
  -----------
  Fix heap buffer overflow (8-byte OOB write) in AES-WRAP-PAD unwrap

On its integrity-failure paths that primitive writes and cleanses up to inlen
bytes of the output buffer. Size the buffer for that worst case so a failed
unwrap cannot write past the allocation.

Fixes CVE-2026-63072

Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Merge-date: Mon Aug 24 14:37:11 2026


  Commit: 9e55749c83f6b801ef17b069ac6ee74e6487005a
      https://github.com/openssl/openssl/commit/9e55749c83f6b801ef17b069ac6ee74e6487005a
  Author: Daniel Kubec <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M test/cmsapitest.c
    M test/recipes/80-test_cmsapi.t

  Log Message:
  -----------
  Add test for CVE-2026-63072

Assisted-by: Claude:claude-fable-5
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Norbert Pocs <[email protected]>
Merge-date: Mon Aug 24 14:37:11 2026


  Commit: 809b52282a3ea6d56fc2e1c427f2d9bd83b06eaa
      https://github.com/openssl/openssl/commit/809b52282a3ea6d56fc2e1c427f2d9bd83b06eaa
  Author: Matt Caswell <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M ssl/record/methods/dtls_meth.c

  Log Message:
  -----------
  Avoid full read buffer allocation when buffering DTLS next-epoch records

dtls_rlayer_buffer_record() buffers records that arrive early for the
next epoch while a handshake is in progress. It did this by taking
ownership of the entire live read buffer (sized for the largest
possible record, ~16.7KB) and allocating a brand new one to carry on
reading, regardless of how small the buffered record actually was.
With the queue capped at 100 entries, a peer could send around 100
tiny bogus next-epoch records (~14 bytes each on the wire) and force
around 1.7MB of heap allocation per connection.

Instead, copy only the record's own on-wire bytes (header and
ciphertext) into the queue entry, and leave the live read buffer
untouched. Memory use is now proportional to what the peer actually
sends.

Fixes CVE-2026-54874

Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Merge-date: Mon Aug 24 15:37:50 2026


  Commit: 24a394e0b9c0afded88f57343fd491d26ca5bd5f
      https://github.com/openssl/openssl/commit/24a394e0b9c0afded88f57343fd491d26ca5bd5f
  Author: Matt Caswell <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M ssl/record/methods/dtls_meth.c

  Log Message:
  -----------
  ssl/record/methods/dtls_meth.c: lower the unprocessed_rcds queue limit

100 buffered next-epoch records is far more than a normal handshake
ever needs. A peer that has already completed its side of the epoch
transition may send more than one record under the new epoch before
we catch up and bump our own receive epoch - for example, application
data sent immediately once the peer considers the handshake done -
but real-world bursts like that are still small. Now that each entry
only costs as much memory as the record actually received, the limit
mainly serves as a ceiling on worst-case per-connection memory use, so
lower it to 16 to keep that ceiling smaller while still leaving ample
headroom over legitimate usage.

Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Merge-date: Mon Aug 24 15:37:51 2026


  Commit: 2fbe637d98b77252e65ff4c367f56210c9a026e6
      https://github.com/openssl/openssl/commit/2fbe637d98b77252e65ff4c367f56210c9a026e6
  Author: Matt Caswell <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M ssl/record/methods/dtls_meth.c
    M ssl/record/methods/recmethod_local.h

  Log Message:
  -----------
  ssl/record: remove dead DTLS processed_rcds record queue

rl->processed_rcds and the functions that serviced it
(dtls_copy_rlayer_record(), dtls_retrieve_rlayer_buffered_record())
were unreachable: nothing in the codebase ever inserted a record into
that queue, so the only consumer of it - the check at the top of
dtls_get_more_records() - always saw an empty queue. The real
mechanism for handing buffered next-epoch records to the next epoch's
record layer is the unrelated forwarding code in dtls_free(), which
pushes the raw bytes from rl->unprocessed_rcds onto rl->next.

Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Merge-date: Mon Aug 24 15:37:52 2026


  Commit: b6011a9ee87ab25f47d999a716a1567da00e1878
      https://github.com/openssl/openssl/commit/b6011a9ee87ab25f47d999a716a1567da00e1878
  Author: Alexandr Nedvedicky <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M include/internal/quic_record_rx.h
    M ssl/quic/quic_port.c
    M ssl/quic/quic_record_rx.c

  Log Message:
  -----------
  Avoid double free of qrx in port_default_packet_handler()

port_default_packet_handler() may perform double free of qrx
when channel creation fails. The port_default_packet_handler()
transfers ownership of qrx to channel/connection via call to
port_bind_channel(). The port_bind_channel() however may
release the qrx when channel can not be bound. The error is
then detected in port_default_packet_handler() which then agains
releases qrx for the second time.

The fix is to add a reference counter to QRX object so transfer
of ownership between port_default_packet_handler() and QUIC_CHANNEL
can be handled safely.

Fixes CVE-2026-18798

Reviewed-by: Igor Ustinov <[email protected]>
Reviewed-by: Andrew Dinh <[email protected]>
Merge-date: Mon Aug 24 15:46:13 2026


Compare: https://github.com/openssl/openssl/compare/d44817c5cb03...b6011a9ee87a

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/d44817-b6011a%40github.com.