openssl, branch dependabot/github_actions/dtolnay/rust-toolchain-e2a55d2ffb04f378e9626c28d38b36d230d1e12f

Dependabot update

2026-10-15T17:32:58Z

CLA: trivial (deps): Bump dtolnay/rust-toolchain Bumps [dtolnay/rust-toolchain](https://github.com/dtolnay/rust-toolchain) from 0f44b27771c32bda9f458f75a1e241b09791b331 to e2a55d2ffb04f378e9626c28d38b36d230d1e12f. - [Release notes](https://github.com/dtolnay/rust-toolchain/releases) - [Commits](https://github.com/dtolnay/rust-toolchain/compare/0f44b27771c32bda9f458f75a1e241b09791b331...e2a55d2ffb04f378e9626c28d38b36d230d1e12f) --- updated-dependencies: - dependency-name: dtolnay/rust-toolchain dependency-version: e2a55d2ffb04f378e9626c28d38b36d230d1e12f dependency-type: direct:production ... Signed-off-by: dependabot[bot]

test/cmp_vfy_test.c: prevent memory leak in test_msg_check_update_malicious_sender

2026-10-15T11:49:31Z

In test_msg_check_update_malicious_sender(), expected and actual were allocated via X509_NAME_new() prior to SETUP_TEST_FIXTURE(). If set_up() failed, SETUP_TEST_FIXTURE() returned early, leaking both allocated X509_NAME objects. Defer allocation until after SETUP_TEST_FIXTURE(), initialize both pointers to NULL, and allocate them safely within the TEST_ptr() validation chain. On setup or validation failure, both pointers and the test fixture are freed cleanly. Resolves: https://github.com/openssl/openssl/issues/33200 Fixes: a6286cd01801 "Add test for CVE-2026-63073" CLA: trivial Signed-off-by: jdymitarai Reviewed-by: Neil Horman Reviewed-by: Eugene Syromiatnikov Reviewed-by: Nikola Pajkovsky Merge-date: Thu Oct 15 11:51:16 2026 Merged-from: https://github.com/openssl/openssl/pull/33203

test/dtlsssllistenertest.c: fix flaky zero-wait handshake loops

2026-10-14T11:38:56Z

test_dtls_listener_max_dgram_size_functional() and test_dtls_notifier_signalled_on_accept_queue_push() drive a real loopback UDP handshake in a fixed 100-iteration loop that polls with a zero timeout and never sleeps between attempts. If loopback delivery lags - as it does intermittently on macOS CI runners - the loop can exhaust its budget before a datagram becomes readable and the test fails with "did not converge", even though the listener is working correctly. This is the same bug fixed in drive_until_connection_queued() by 271222650b ("dtls: fix flaky cookie exchange loop in listener test"). Apply the same treatment here: sleep 10ms between iterations so a delayed datagram has time to arrive, and raise the iteration cap to 200 so the budget still covers the client's 1s initial retransmit timer if a datagram is lost outright. Every other real-socket convergence loop in the file already waits on the SSL_poll() call itself (poll_timeout.tv_usec = 100000) rather than busy-spinning, and the remaining zero-timeout loops are backed by an in-memory dgram BIO pair with synchronous delivery, so neither needed this fix. Assisted-by: Claude:claude-sonnet-5 Reviewed-by: Jakub Zelenka Reviewed-by: Mounir Idrassi Reviewed-by: Eugene Syromiatnikov Merge-date: Wed Oct 14 11:41:42 2026 Merged-from: https://github.com/openssl/openssl/pull/32673

DTLS listener: bound the demux free list

2026-10-14T10:53:51Z

The demux free list caches released URXEs so a receive burst can be served without allocating, but nothing bounds it: a transient flood raising the per-connection receive queues also raises the free list's retained high-water mark for the remaining lifetime of the listener. Add a per-demux limit, ossl_dgram_demux_set_max_free_urxe(), enforced in ossl_dgram_demux_release_urxe(): a URXE released while the free list is at its limit is freed instead of cached, so the bound is strict and no later trim pass is needed. Freeing there honours the documented contract that no reference may be made to a URXE or its buffer after it is released, and no release caller touches the entry afterwards. The DTLS listener sets the limit to DEMUX_MAX_FREE_URXE, two receive batches, so one full batch can always be cached; QUIC keeps the default unbounded behaviour. Resolves: https://github.com/openssl/openssl/issues/33173 Assisted-by: Claude Code:moonshotai/kimi-k3 Reviewed-by: Tomas Mraz Reviewed-by: Ryan Hooper Reviewed-by: Eugene Syromiatnikov Merge-date: Wed Oct 14 10:54:56 2026 Merged-from: https://github.com/openssl/openssl/pull/33197

DTLS listener: make max_pending_conns a combined admission budget

2026-10-14T10:51:10Z

The pending-connection cap only applied to pending_conns, the table of connections still doing their handshake: the moment a connection passed cookie validation it was moved onto the accept queue (incoming_connections) with no length check and no expiry. A reachable peer completing the ordinary cookie exchange from many source endpoints could accumulate an unbounded, unexpiring queue of listener-owned SSL objects. This is the same missing admission bound as the QUIC listener admission check fixed in [1]; the DTLS listener is new in 4.1 and not in any final release. Mirror the QUIC fix: enforce the bound at admission, in the packet handler, before any per-connection state is allocated. SSL_VALUE_DTLS_LISTENER_MAX_PENDING_CONNS is now a single admission budget covering both listener-owned tables, pending plus accept queue, so listener-owned connections are bounded at N in total, including under SSL_LISTENER_FLAG_NO_VALIDATE. Moving a connection from one table to the other leaves the total unchanged, so a validated connection can always be queued: none is discarded, and no handshake work (cookie exchange, server flight) is spent on an attempt that cannot be admitted. A peer whose datagram is dropped while the budget is exhausted retransmits its ClientHello and is admitted once the application drains the queue; measured on real UDP, such a client completes its handshake about one retransmit interval after the drain. This also aligns the DTLS knob's meaning with the QUIC one ("not yet accepted"), which it was modelled on in [2]. Accept-queue entries still do not expire; a full queue stays full until the application drains it. With the budget, an attacker can pin at most N accept-queue slots, and only after proving return routability - spoofed ClientHellos can still occupy pending slots until the pending timeout reaps them, as before this change - so what remains is a bounded availability concern, not memory exhaustion. [1] https://github.com/openssl/openssl/pull/32052 [2] https://github.com/openssl/openssl/pull/31980 Resolves: https://github.com/openssl/openssl/issues/33172 Assisted-by: Claude Code:moonshotai/kimi-k3 Reviewed-by: Tomas Mraz Reviewed-by: Ryan Hooper Reviewed-by: Eugene Syromiatnikov Merge-date: Wed Oct 14 10:54:55 2026 Merged-from: https://github.com/openssl/openssl/pull/33197

DTLS listener: bound the per-connection receive queue

2026-10-14T10:49:39Z

The DTLS listener queues datagrams from a known peer into a per-connection list (DTLS_RX::urxe_pending) with no limit on count or bytes. A reachable peer that completes the ordinary cookie exchange can grow one parked connection's queue without bound as long as the application keeps the shared demux pumped, moving datagrams into userspace past the bound the kernel socket buffer would otherwise provide. Cap the queue at OSSL_DTLS_RX_DEFAULT_MAX_QUEUED (128) datagrams per connection - a datagram count, not a byte cap. Every queued URXE holds a buffer of at least the listener's maximum datagram size whatever the datagram's length, so a full queue costs about 295 KB per connection at the default 2000-byte size, roughly one default kernel socket receive buffer; across a full 256-connection listener budget that is about 75 MB. The queue is consumed FIFO, so on overflow the oldest datagram is evicted rather than the newest: a DTLS flight can span several datagrams, and under overload keeping the newest biases the queue toward the flight the peer just sent instead of stale fragments of an older one. The evicted URXE is unhooked under rx->mutex and released to the demux after dropping it, so demux->mutex is never taken while rx->mutex is held. References: https://github.com/openssl/openssl/issues/33173 Assisted-by: Claude Code:moonshotai/kimi-k3 Reviewed-by: Tomas Mraz Reviewed-by: Ryan Hooper Reviewed-by: Eugene Syromiatnikov Merge-date: Wed Oct 14 10:54:54 2026 Merged-from: https://github.com/openssl/openssl/pull/33197

AEAD regression test for EVP_CIPHER_do_all_provided

2026-10-13T15:22:01Z

... combined with a sanity check for expected AEAD algs in a static list. - every cipher in aead_algs[] must be discovered - every discovered cipher must be in aead_algs[] Meant to catch: - ciphers falling out of dynamic discovery for unexpected reasons - ciphers discovered dynamically for unexpected reasons Could happen for reasons like build system errors, flags shifting, etc. Assisted-by: Claude:claude-fable-5-1 Reviewed-by: Neil Horman Reviewed-by: Saša Nedvědický Reviewed-by: Eugene Syromiatnikov Merge-date: Tue Oct 13 15:22:55 2026 Merged-from: https://github.com/openssl/openssl/pull/32842

crypto/x509/x509_lu.c: avoid freeing X509_OBJECTs in X509_STORE_get0_objects()

2026-10-13T13:45:08Z

The implementation of hash table conversion in commit 04589b59ef50 "x509store: reduce lock contention in X509_STORE" introduced a potential use-after-free condition when X509_STORE_get0_objects() is called during X.509 verification. Avoid that by re-using existing X509_OBJECTs instead of duplicating them. Resolves: https://github.com/openssl/openssl/issues/33063 Fixes: 04589b59ef50 "x509store: reduce lock contention in X509_STORE" Signed-off-by: Eugene Syromiatnikov Reviewed-by: Mounir Idrassi Reviewed-by: Nikola Pajkovsky Merge-date: Tue Oct 13 13:45:39 2026 Merged-from: https://github.com/openssl/openssl/pull/33147

test: migrate test_aes_siv_ctx_enc_retval from evp_extra_test.c to evp_aead_test.c

2026-10-12T13:14:27Z

Move test_aes_siv_ctx_enc_retval() out of test/evp_extra_test.c into test/evp_aead_test.c, rename it to test_evp_aead_enc_retval() and run it over aead_list instead of only AES-128-SIV. The check is that after a completed encrypt, a further EVP_EncryptUpdate() on the same context is rejected, and the EVP_EncryptFinal_ex() that follows fails as well, instead of reporting the earlier success. GCM, OCB and ASCON mark the context finished. SIV stores the result of the last operation, so a rejected Update makes the following Final fail. CCM, GCM-SIV and ChaCha20-Poly1305 are skipped: Final currently succeeds after the rejected Update, and what it should do is not settled yet. ChaCha20-Poly1305 reports the same mode as ASCON, so it is matched by name. Key and IV are sized from the resolved cipher parameters, the context is set up with EVP_EncryptInit_ex2(), and the tag is fetched after Final with OSSL_PARAM. Assisted-by: Claude:claude-sonnet-5 Reviewed-by: Neil Horman Reviewed-by: Nikola Pajkovsky Reviewed-by: Eugene Syromiatnikov Merge-date: Mon Oct 12 13:15:18 2026 Merged-from: https://github.com/openssl/openssl/pull/33135

Migrate test_evp_final_no_tag to evp_aead_test.c

2026-10-11T22:26:39Z

Move test_evp_final_no_tag out of evp_extra_test.c into evp_aead_test.c and run it over every AEAD in aead_list instead of a hardcoded pair of ciphers. The check is that EVP_DecryptFinal_ex() refuses to finalize a decrypt when no tag has been set. CCM, OCB, SIV and GCM-SIV are skipped for now. Those modes either require the tag and payload length to be declared before the payload update, or verify inside the payload update rather than in final, so the check as written does not apply to them. How the interface should behave for these modes is still under discussion. Key and IV buffers are sized to EVP_MAX_KEY_LENGTH and EVP_MAX_IV_LENGTH so ciphers with longer keys, such as AES-256-SIV, stay in bounds, and the keylen, ivlen and taglen of each cipher are checked against those buffers. Encryption and decryption use separate contexts, initialized with EVP_*Init_ex2(), and the decrypt final writes to the plaintext buffer. Assisted-by: Claude:claude-sonnet-5 Reviewed-by: Neil Horman Reviewed-by: Saša Nedvědický Reviewed-by: Eugene Syromiatnikov Merge-date: Sun Oct 11 22:27:06 2026 Merged-from: https://github.com/openssl/openssl/pull/32907