openssl/include, branch openssl-3.5.9

Copyright year updates

2026-09-29T14:02:59Z

Reviewed-by: Eugene Syromiatnikov Reviewed-by: Tomas Mraz Merge-date: Tue Sep 29 14:02:59 2026 Release: yes

ec: make ossl_ec_scalar_mul_ladder() scalar padding constant time

2026-09-29T11:26:17Z

Fixes CVE-2026-54872 Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alicja Kario Reviewed-by: Viktor Dukhovni Merge-date: Tue Sep 29 11:26:21 2026

Defer computation of relative CRLDP names

2026-09-29T11:15:35Z

These are derived just-in-time, during any actual CRL processing. Fixes CVE-2026-35189 Reviewed-by: Bob Beck Reviewed-by: Norbert Pocs Merge-date: Tue Sep 29 11:15:39 2026

Enforce final size for streams.

2026-09-26T11:53:21Z

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: Milan Broz Merge-date: Sat Sep 26 11:53:41 2026 Merged-from: https://github.com/openssl/openssl/pull/32769

Limit packet buffer overhead to ~64kB per stream.

2026-09-26T11:53:21Z

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: Milan Broz Merge-date: Sat Sep 26 11:53:40 2026 Merged-from: https://github.com/openssl/openssl/pull/32769

New implementation of stream reassembly for QUIC.

2026-09-26T11:53:21Z

The new implementation makes clear distinction between stream chunk and stream range. The strem chunk is defined by its `start` and `end` offset with respect to offset 0 (the start of the stream). The `start` < `end`. The lenght of the stream chunk is `end - start`. The stream chunks are delivered as QUIC stream frames. The stream range is list of stream chunks which together create one continuous range of stream. The range is also deined by `start` and `end` offset. The ranges are kept in R/B tree. The chunks which are arriving in order are kept in list which forms one node of R/B tree. If newly arriving stream chunk can not be inserted to existing stream range for example because chunk.start > range.end (there is a gap between existing range and new chunk), then the new range is created and inserted to R/B tree. If the newly arriving chunk closes the gap between two existing ranges, the ranges are merged to single tree node. The join proces uses list join operation with O(1) complexity to make the new continuous range of stream chunks. In a nutshell: stream reassembly process is R/B tree look up/insert with tail/head insertion to list. There is also a preparatory work that will allow us to deal with memory hog issue. Currently the QUIC stack keeps all stream frame data on packet buffers until data is moved to application. On hone hand, this saves one copy opration between on the other hand it may cause receiver to hold lot more memory than currently needed. Consider situation where QUIC stack needs to hold reference to whole packet buffer, just because of sinle 1byte stream chunk. The 1byte stream chunk (at let's say offset 10) can not be moved to application yet, because QUIC stack is waiting for data at offset 0 - 9. Such buffer might be waiting in reassembly queue for a long time holding a reference to whole packet. To mitigate this we need to allow the QUIC stack to move data from packet buffers to stream buffers. The logic which decides when data should be moved from packet buffers is missing in this change. Here we just bring the code that supports improved buffer handling. The data for short stream frames/chunks (16B) are kept inside the stream chunk structure itself (this is referred as direct storage, or dstorage). The code coalesces data from adjacent stream frames into dstorage until it fill up. Once dstorage is full the new stream chunk is allocated and added to range. Larger stream chunks (size > 16B) get buffer from the heap. It is then linked to stream buffer. This commit just brings the quic_strm_reas.c in. It is not currently hooked to build. Fixes: CVE-2026-42772 Co-authored-by: Tomáš Mráz Co-authored-by: Jakub Zelenka Co-authored-by: Mounir IDRASSI Reviewed-by: Tomas Mraz Reviewed-by: Milan Broz Merge-date: Sat Sep 26 11:53:39 2026 Merged-from: https://github.com/openssl/openssl/pull/32769

Add a red-black tree implementation

2026-09-26T11:53:21Z

The code comes from David Gwynne . The same implmentation can be found in OpenBSD. Several minor adjustments have been done to include the code into OpenSSL: * the prefix has been changed to OSSL_RBT_, * the support augment is removed, * _RBT_CHECK()/_RBT_POISON() got removed too, * _RB_REMOVE() resets link pointer to NULL in debug build, The documentation is based on tree(3) from OpenBSD, originally authored by Niels Provos . Co-Authoerd-by: David Gwynne Co-Authored-by: Niels Provos Co-Authored-by: Andrew Dinh Reviewed-by: Eugene Syromiatnikov Reviewed-by: Bob Beck Reviewed-by: Norbert Pocs MergeDate: Tue Aug 11 19:15:59 2026 Reviewed-by: Tomas Mraz Reviewed-by: Milan Broz Merged-from: https://github.com/openssl/openssl/pull/32769

refcount: declare Windows CRYPTO_REF_COUNT as volatile long

2026-09-25T10:51:42Z

_InterlockedExchangeAdd() is prototyped as LONG _InterlockedExchangeAdd(volatile LONG *, LONG) but CRYPTO_REF_COUNT held a volatile int. The MSVC branch passed &refcnt->val straight in, which does not compile: refcount.h(189): note: 'LONG _InterlockedExchangeAdd(volatile LONG *,LONG)': cannot convert argument 1 from 'volatile int *' to 'volatile LONG *' refcount.h(189): note: Types pointed to are unrelated Declare val as volatile long in both the __ICL/_WIN32 and the _MSC_VER variants and drop the cast, so the object type matches what the intrinsic operates on. Fixes: https://github.com/openssl/openssl/issues/21080 Signed-off-by: Nikola Pajkovsky Reviewed-by: Mounir Idrassi Reviewed-by: Neil Horman Merge-date: Fri Sep 25 10:51:43 2026 Merged-from: https://github.com/openssl/openssl/pull/32819

quic: collect rejected incoming streams and return their stream credit

2026-09-24T09:10:55Z

A stream rejected by the incoming stream policy is never placed on the accept queue, so it is never retired for the purposes of MAX_STREAMS RXFC and the peer is never granted credit for another stream. After the initial limit of 100 streams has been reached, the peer cannot open any further stream for the lifetime of the connection. Such a stream is also never garbage collected. Rejecting a stream resets its send part, which frees the send stream, and the acknowledgement handler skips a chunk whose send stream is already gone before it confirms the STOP_SENDING and RESET_STREAM frames. The stream therefore never records that its STOP_SENDING was acknowledged, never becomes ready for garbage collection and remains in the stream map until the connection is torn down. Confirm both frames even when the send stream has already been freed, and retire the stream for MAX_STREAMS RXFC when it is rejected. The two changes belong together: returning the stream credit on its own would replace a leak bounded by the stream limit with an unbounded one. Assisted-by: Claude:claude-fable-5 Reviewed-by: Tomas Mraz Reviewed-by: Saša Nedvědický Merge-date: Thu Sep 24 09:10:59 2026 Merged-from: https://github.com/openssl/openssl/pull/32698

Re-format code after TypenameMacros and ForEachMacros additions

2026-09-24T09:04:03Z

Re-formatting was done using the following command: for i in `git grep -l 'OSSL_LIST\|PRIORITY_QUEUE_OF\|SPARSE_ARRAY_OF' \ -- '*.c' '*.h' '*.c.in' '*.h.in'`; do \ clang-format-21 --style=file:.clang-format -i "$i"; \ done Signed-off-by: Eugene Syromiatnikov Reviewed-by: Milan Broz Reviewed-by: Nikola Pajkovsky Merge-date: Thu Sep 24 09:04:09 2026 Merged-from: https://github.com/openssl/openssl/pull/32305