openssl/include/internal, branch master

Fix SSL_poll() multi-reactor cleanup deadlock

2026-10-20T12:28:57Z

SSL_poll() cleaned up QUIC reactor wait registrations in item-array order. Leaving a reactor can block while its notifier is signalled, so two callers spanning the same reactors could each wait on one reactor while still registered on another. The translation abort path has the same ordering problem. Split QUIC leave into two phases: deregister from every QUIC reactor, then wait for any notification cycles still pending. For QUIC-only poll sets this removes every waiter registration before any notifier wait. DTLS listener cleanup is unchanged. Guard the QUIC drain call for no-quic builds. Phase 2 also prevents an immediate re-registration from keeping the notifier signalled. Capture notify_generation during deregistration so a wait is bounded to the observed cycle. Apply the same generation bound to the combined single-reactor leave operation. Exercise real SSL_poll cleanup on two reactors in both the post-poll and translation-abort paths, including repeated items sharing a reactor. Check that a delayed phase-2 waiter completes while a later notification cycle remains signalled. Fixes #32130 Assisted-by: OpenCode:GLM-5.2 Assisted-by: Codex:gpt-5.6-sol Assisted-by: Codex:gpt-6-astra Reviewed-by: Tomas Mraz Reviewed-by: Neil Horman Merge-date: Tue Oct 20 12:29:05 2026 Merged-from: https://github.com/openssl/openssl/pull/32137

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: 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

Change all files with OpenSSL License to ASL 2.0 License

2026-10-05T09:34:43Z

Reviewed-by: Eugene Syromiatnikov Reviewed-by: Dmitry Belyavskiy Reviewed-by: Simo Sorce Reviewed-by: Paul Dale Merge-date: Mon Oct 5 09:34:48 2026 Merged-from: https://github.com/openssl/openssl/pull/33070

Build the qlog filename with asprintf

2026-10-02T07:18:03Z

Replaces the length arithmetic and per-byte snprintf hex loop. id_len is asserted against QUIC_MAX_CONN_ID_LEN, which the wire parser already enforces. ossl_determine_dirsep was awkwardly a char, with only one caller being this function - remove it from internal/common.h and make it a static returning a string. Reviewed-by: Nikola Pajkovsky Reviewed-by: Andrew Dinh Merge-date: Fri Oct 2 07:18:25 2026 Merged-from: https://github.com/openssl/openssl/pull/31550

Provide ossl_asprintf() and friends.

2026-10-02T07:18:02Z

From BoringSSL Fixes: https://github.com/openssl/project/issues/1914 Reviewed-by: Nikola Pajkovsky Reviewed-by: Andrew Dinh Merge-date: Fri Oct 2 07:18:13 2026 Merged-from: https://github.com/openssl/openssl/pull/31550

DTLS 1.3: Retain the previous read epoch to recover from lost ACKs

2026-10-02T06:36:26Z

After processing the client's Finished or a peer KeyUpdate, the read record layer advanced to the new epoch and the old one was freed immediately. If the ACK we sent for that message was lost, the peer's retransmission arrived at the now-discarded epoch: it could not be authenticated, so no replacement ACK was ever produced and the peer exhausted its retransmission budget. RFC9147 section 5.8.1 requires the finished peer to ACK retransmissions of the other side's final flight, and section 8 requires receive keys from before a KeyUpdate to be retained until decryption with the new keys succeeds. Retain exactly one prior read epoch's record layer instead of freeing it, add a record-layer dispatch hook so the DTLS method can take ownership of it, and authenticate a record at that epoch with its own retained keys and replay window when the current epoch's epoch-bits check would otherwise just drop it. This isn't limited to replacing lost ACKs: a previous *application* epoch (from KeyUpdate recovery) can also legitimately supply application data that arrives reordered relative to the epoch change. Successful authentication with the retained keys doesn't by itself prove a record is a retransmission, so let it reach the handshake layer instead of deciding that here: the DTLS 1.2-only Finished special case (retransmit our own flight) is skipped for DTLS 1.3, and the existing out-of-sequence duplicate-ACK path is widened from post-handshake epochs only to include the epoch a Finished is sent at -- the sequence and epoch checks in that path are what actually decide whether a retained-epoch record can be acknowledged. Fixes: #32891 Assisted-by: Claude:claude-sonnet-5 Reviewed-by: Mounir Idrassi Reviewed-by: Tomas Mraz Merge-date: Fri Oct 2 06:36:27 2026 Merged-from: https://github.com/openssl/openssl/pull/32963

Fix coding style violation: do not use variable length arrays

2026-09-29T16:39:51Z

Signed-off-by: Nicky Mouha Reviewed-by: Neil Horman Reviewed-by: Paul Dale Reviewed-by: Tomas Mraz Merge-date: Tue Sep 29 16:40:02 2026 Merged-from: https://github.com/openssl/openssl/pull/32967

Enforce final size for streams.

2026-09-26T11:35:08Z

When FIN stream frame is received at particular offset, then the FIN's offset must be the largest offset kept in stream reassembly buffer. Receiving stream frame with offset larger than FIN frame must be reported as protocol violation and connection must be closed. In order to report protocol violation error the stream reassembly module must have a reference to QUIC_CHANNEL object where particular stream belongs to. The refernce to channel is part of QUIC_RSTREAM_QPARAM structure. This change makes stream quality parameter mandatory. Co-authored-by: Jakub Zelenka Reviewed-by: Tomas Mraz Reviewed-by: Mounir Idrassi Merge-date: Sat Sep 26 11:35:33 2026 Merged-from: https://github.com/openssl/openssl/pull/32038

Limit packet buffer overhead to ~64kB per stream.

2026-09-26T11:35:08Z

There is currently no limit on how many bytes of packet buffers each stream can hold in memory. To monitor and limit the size of packet buffers used by stream the change accounts so called stream chunk overhead which is a delta between actual datagram size of packet delivering the particular stream chunk and chunk itself. As soon as the chunk overhead exceeds ~64kB for all stream chunks kept in receive buffer, the newly received chunks will be moved from packet buffer to stream buffer. The packet buffer overhead limit is held in newly introduced structure QUIC_RSTREAM_QPARAM (RX stream quality parameter). If new additional quality parameters are added, then those should be part of QUIC_RSTREAM_QPARAM structure. this changeset introduces QUIC_RSTREAM_QPARAM the the rsqp (reead stream quality parameter) enables channel to control quality of RX stream. quality currently means the packet buffer overhead. more parameters may be added later. Fixes: CVE-2026-54873 Reviewed-by: Tomas Mraz Reviewed-by: Mounir Idrassi Merge-date: Sat Sep 26 11:35:32 2026 Merged-from: https://github.com/openssl/openssl/pull/32038