CVE-2026-84784

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols.

Security Fix(es):

Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions.

Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates.

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations.

The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received.

FIPS impact: no The affected code is outside the FIPS module boundary.(CVE-2026-35189)

Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received.

Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack.

CWE: CWE-440: Expected Behavior Violation

Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed.

The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC.

FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.(CVE-2026-35191)

Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data.

Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth.

CWE: CWE-407: Inefficient Algorithmic Complexity

Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current tail.

By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process.

FIPS impact: no The…

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

DTLS Retransmits Handshake Messages From a Stale Buffer Offset. (CVE-2026-84782) Excessive Memory Allocation in Relative CRLDP Processing. (CVE-2026-35189) QUIC Unvalidated Amplification Credit may be Over Accounted. (CVE-2026-35191) Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC. (CVE-2026-42772) Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves. (CVE-2026-54872) QUIC STREAM Fragment Metadata DoS. (CVE-2026-54873) Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V. (CVE-2026-54875) Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake. (CVE-2026-72897) QUIC Connection-Level Flow Control is Not Enforced for Streams. (CVE-2026-75804) NULL Pointer Dereference in CMP Client Revocation Response Handling. (CVE-2026-75805) Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS. (CVE-2026-75806) Timing Side-Channel in SM2 Signature Generation. (CVE-2026-77696) QUIC: Unbounded RETIRE_CONNECTION_ID Backlog. (CVE-2026-84784)

This update for openssl-3 fixes the following issues:

• CVE-2026-35189: Excessive Memory Allocation in Relative CRLDP Processing (bsc#1280589).
• CVE-2026-35191: QUIC Unvalidated Amplification Credit may be Over Accounted (bsc#1280590).
• CVE-2026-54872: Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves (bsc#1280591).
• CVE-2026-54875: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V (bsc#1280592).
• CVE-2026-72897: Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake (bsc#1280594).
• CVE-2026-75804: QUIC Connection-Level Flow Control is Not Enforced for Streams (bsc#1280595).
• CVE-2026-75805: NULL Pointer Dereference in CMP Client Revocation Response Handling (bsc#1280596).
• CVE-2026-75806: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS (bsc#1280597).
• CVE-2026-77696: Timing Side-Channel in SM2 Signature Generation (bsc#1280598).
• CVE-2026-84782: DTLS Retransmits Handshake Messages From a Stale Buffer Offset (bsc#1280587).
• CVE-2026-84784: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog (bsc#1280599).

This update for openssl-3 fixes the following issues:

• CVE-2026-35189: Excessive Memory Allocation in Relative CRLDP Processing (bsc#1280589).
• CVE-2026-35191: QUIC Unvalidated Amplification Credit may be Over Accounted (bsc#1280590).
• CVE-2026-54872: Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves (bsc#1280591).
• CVE-2026-54875: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V (bsc#1280592).
• CVE-2026-72897: Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake (bsc#1280594).
• CVE-2026-75804: QUIC Connection-Level Flow Control is Not Enforced for Streams (bsc#1280595).
• CVE-2026-75805: NULL Pointer Dereference in CMP Client Revocation Response Handling (bsc#1280596).
• CVE-2026-75806: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS (bsc#1280597).
• CVE-2026-77696: Timing Side-Channel in SM2 Signature Generation (bsc#1280598).
• CVE-2026-84782: DTLS Retransmits Handshake Messages From a Stale Buffer Offset (bsc#1280587).
• CVE-2026-84784: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog (bsc#1280599).

This update for openssl-3 fixes the following issues:

• CVE-2026-35189: Excessive Memory Allocation in Relative CRLDP Processing (bsc#1280589).
• CVE-2026-35191: QUIC Unvalidated Amplification Credit may be Over Accounted (bsc#1280590).
• CVE-2026-54872: Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves (bsc#1280591).
• CVE-2026-54875: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V (bsc#1280592).
• CVE-2026-72897: Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake (bsc#1280594).
• CVE-2026-75804: QUIC Connection-Level Flow Control is Not Enforced for Streams (bsc#1280595).
• CVE-2026-75805: NULL Pointer Dereference in CMP Client Revocation Response Handling (bsc#1280596).
• CVE-2026-75806: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS (bsc#1280597).
• CVE-2026-77696: Timing Side-Channel in SM2 Signature Generation (bsc#1280598).
• CVE-2026-84782: DTLS Retransmits Handshake Messages From a Stale Buffer Offset (bsc#1280587).
• CVE-2026-84784: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog (bsc#1280599).

This update for openssl-3 fixes the following issues:

• CVE-2026-35189: Excessive Memory Allocation in Relative CRLDP Processing (bsc#1280589).
• CVE-2026-35191: QUIC Unvalidated Amplification Credit may be Over Accounted (bsc#1280590).
• CVE-2026-54872: Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves (bsc#1280591).
• CVE-2026-54875: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V (bsc#1280592).
• CVE-2026-72897: Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake (bsc#1280594).
• CVE-2026-75804: QUIC Connection-Level Flow Control is Not Enforced for Streams (bsc#1280595).
• CVE-2026-75805: NULL Pointer Dereference in CMP Client Revocation Response Handling (bsc#1280596).
• CVE-2026-75806: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS (bsc#1280597).
• CVE-2026-77696: Timing Side-Channel in SM2 Signature Generation (bsc#1280598).
• CVE-2026-84782: DTLS Retransmits Handshake Messages From a Stale Buffer Offset (bsc#1280587).
• CVE-2026-84784: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog (bsc#1280599).

Other non-security fixes:

• Add a conflicts with previous crypto-policies versions (bsc#1281125)

It was discovered that OpenSSL incorrectly handled certain certificate revocation list distribution point names. An attacker could possibly use this issue to cause OpenSSL to consume excessive memory, resulting in a denial of service. (CVE-2026-35189)

It was discovered that OpenSSL incorrectly handled QUIC unvalidated amplification credit accounting. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-35191)

It was discovered that OpenSSL incorrectly implemented scalar multiplication for non-NIST elliptic curves. An attacker could possibly use this issue to perform a timing side-channel attack and obtain sensitive information. (CVE-2026-54872)

It was discovered that OpenSSL incorrectly implemented SM2 scalar multiplication on ARM64 and RISC-V architectures. An attacker could possibly use this issue to perform a timing side-channel attack and obtain sensitive information. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-54875)

It was discovered that OpenSSL incorrectly handled SSL context switching during a TLS handshake. An attacker could possibly use this issue to cause an out-of-bounds read, resulting in a denial of service or obtaining sensitive information. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-72897)

It was discovered that OpenSSL incorrectly enforced QUIC connection- level flow control for streams. An attacker could possibly use this issue to cause OpenSSL to consume excessive memory, resulting in a denial of service. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-75804)

It was discovered that OpenSSL incorrectly handled a NULL pointer in CMP client revocation response processing. An attacker could possibly use this issue to cause a denial of service. (CVE-2026-75805)

It was discovered that OpenSSL incorrectly handled undersized DTLS 1.2 AEAD records before authentication. An attacker could possibly use this issue to cause a denial of service. (CVE-2026-75806)

It was discovered that OpenSSL incorrectly implemented SM2 signature generation. An attacker could possibly use this issue to perform a timing side-channel attack and obtain sensitive information. (CVE-2026-77696)

It was discovered that OpenSSL incorrectly handled DTLS retransmission of handshake messages. An attacker could possibly use this issue to cause incorrect handshake behavior or a denial of service. (CVE-2026-84782)

It was discovered that OpenSSL incorrectly handled QUIC RETIRE_CONNECTION_ID frames. An attacker could possibly use this issue to cause OpenSSL to consume excessive memory, resulting in a denial of service. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-84784)