Debian Patches

Status for openssl/3.5.7-1~deb13u2

Patch Description Author Forwarded Bugs Origin Last update
debian-targets.patch debian-targets Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> no 2017-11-05
man-section.patch man-section Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> no 2017-11-05
no-symbolic.patch no-symbolic Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> no 2017-11-05
pic.patch pic Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org> no 2017-11-05
c_rehash-compat.patch also create old hash for compatibility Ludwig Nussel <ludwig.nussel@suse.de> no 2010-04-21
Configure-allow-to-enable-ktls-if-target-does-not-start-w.patch Configure: allow to enable ktls if target does not start with Linux
The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian. So far so good.

Since the target name does not start with `linux', the build system does not
enable ktls. So in order to get enabled, I
added a
`enable => [ "ktls" ],'
to the generic linux config which sets it explicit). Having this set, we can
check for it instead matching the target name.

This commit is based on changes for afalgeng in commit
9e381e8a01859 ("Configure: allow to enable afalgeng if target does not start with Linux")		 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> no 2021-04-01
conf-Serialize-allocation-free-of-ssl_names.patch conf: Serialize allocation/free of ssl_names.
The access to `ssl_names' is not fully serialized. With multiple threads
it is possible that more than one thread starts to clean up `ssl_names'.
This leads to occasional segfaults if more than one terminates and
performs the clean up.		 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> no 2022-09-19
Avoid-double-free-of-qrx-in-port_default_packet_handler.patch 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		 Alexandr Nedvedicky <sashan@openssl.org> no 2026-08-05
Add-test-for-CVE-2026-63072.patch Add test for CVE-2026-63072 Daniel Kubec <kubec@openssl.foundation> no 2026-07-23
Fix-heap-buffer-overflow-8-byte-OOB-write-in-AES-WRAP-PAD.patch 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		 Daniel Kubec <kubec@openssl.foundation> no 2026-08-02
Add-test-for-CVE-2026-63076.patch Add test for CVE-2026-63076 Daniel Kubec <kubec@openssl.foundation> no 2026-07-21
Fix-Remote-NULL-deref-in-ossl_cmp_calc_protection-via-cra.patch 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		 Daniel Kubec <kubec@openssl.foundation> no 2026-07-21
Handle-signature_algorithms_cert-extension-in-key-only-co.patch 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		 Viktor Dukhovni <viktor@openssl.org> no 2026-06-27
Avoid-full-read-buffer-allocation-when-buffering-DTLS-nex.patch 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		 Matt Caswell <matt@openssl.foundation> no 2026-06-23
ssl-record-methods-dtls_meth.c-lower-the-unprocessed_rcds.patch 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.		 Matt Caswell <matt@openssl.foundation> no 2026-06-23
ssl-record-remove-dead-DTLS-processed_rcds-record-queue.patch 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.		 Matt Caswell <matt@openssl.foundation> no 2026-06-23
CMP-unexpected-sender-DN-used-as-format-string-in-ERR_rai.patch 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.


Original patch by: Filipe Casal of Trail of Bits in collaboration with OpenAI		 Norbert Pocs <norbertp@openssl.org> no 2026-07-20
Add-test-for-CVE-2026-63073.patch Add test for CVE-2026-63073 Norbert Pocs <norbertp@openssl.org> no 2026-07-22
Add-a-test-for-restricting-growth-in-cmp-cert-cache.patch 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.		 Neil Horman <nhorman@openssl.org> no 2026-06-30
Fix-unbounded-cert-cache-growth-in-cmp.patch 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		 Neil Horman <nhorman@openssl.org> no 2026-06-30
Don-t-store-ACK-only-frames-in-TX-history-for-QUIC.patch 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 <opal.wright@trailofbits.com>

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



Original patch by Neil Horman <nhorman@openssl.org>		 Norbert Pocs <norbertp@openssl.org> no 2026-08-04
Check-the-tag-on-EVP_Cipher-finalize-Poly1305-and-OCB-AEA.patch Check the tag on EVP_Cipher() finalize: Poly1305 and OCB AEADs
For the affected OpenSSL built-in provider AEAD implementations,
EVP_Cipher(ctx, out, NULL, 0) reaches the ccipher callback as a
NULL-input terminal call. OCB and ChaCha20-Poly1305 took an early exit
on an empty message, with or without AAD, and returned success without
comparing an explicitly supplied tag. Consequently a corrupted tag was
accepted before this change.

Make these built-in callbacks perform their terminal tag operation,
aligning their explicit-tag handling with the streaming Final path
without defining NULL input as part of the generic EVP_Cipher()
contract.

AES-GCM-SIV also failed to generate a tag when Final was its first
empty-message operation. Generate the tag in that case and propagate
failures from the matching empty-message decrypt operation.

The stable ChaCha20-Poly1305 implementation aliases Update to the
one-shot cipher callback, so this backport introduces a dedicated Update
callback to preserve zero-length Update as a no-op.

Follow-up to #31555
Fixes #32258
Fixes CVE-2026-75803


(cherry picked from commit 5741d29a5f356e05262cd0936a472a9961398d53)		 Billy Brumley <bbb@iki.fi> no 2026-08-04
QUIC-server-limit-number-of-pending-QUIC-channels-connect.patch QUIC server: limit number of pending QUIC channels/connections
Currently, there is no limit for pending QUIC connections. The port
default packet handler creates channel for every valid initial packet
which does belong to existing channel (a.k.a. connection). The newly
created channel is inserted to list of pending channels where it waits
to be accepted by local application by call
to SSL_accept_connection(3ossl).

This change introduces a limit for pending connection. The pending
queue is limited to 256 pending connections. Applications may change
the limit by calling SSL_set_feature_request_uint(3ossl)
on SSL server listener object with configurable value
SSL_VALUE_QUIC_MAX_PENDING_CONNS.


(Merged from https://github.com/openssl/openssl/pull/32052)

(cherry picked from commit 9416706d408bb84deb7cee4647bff3045d2dc7ba)
(cherry picked from commit 4084152e040329ca0194c4c1750b9b46d00a5b6b)		 Alexandr Nedvedicky <sashan@openssl.org> no 2026-07-23

All known versions for source package 'openssl'

Links