openssl/include, branch openssl-3.6.3

Copyright year updates

2026-06-09T11:44:35Z

Reviewed-by: Neil Horman Reviewed-by: Saša Nedvědický MergeDate: Tue Jun 9 11:44:36 2026 Release: yes

Add test for path challenge flood mitigation

2026-06-08T14:39:17Z

Client injects 16 path challenge frames. Those are received by server. Only one challenge frame of 16 received triggers path challenge response. Remaining challenge frames are discrded/ignored. Test introduces two counters to channel object: - path_challenge_rx which is bumped for every patch challenge frame received - path_response_tx which is bumped for every path response frame transmitted Succesuful test verifies server receives 16 path challenge frames, but sends just one path response frmae as response. Reviewed-by: Nikola Pajkovsky Reviewed-by: Tomas Mraz MergeDate: Mon Jun 8 14:38:29 2026 (cherry picked from commit 955d15f2e515559f63590da1d106e3a38c6a502e)

QUIC stack must limit the number of PATH_CHALLENGE frames processed in RX

2026-06-08T14:39:17Z

Currently local QUIC stack allocates PATH_RESPONSE frame for every PATH_CHALLENGE frame it receives in single packet from its remote peer. The memory with PATH_RESPONSE frame is released after local QUIC stack receives an ACK which confirms reception of PATH_RESPONSE by remote peer. This gives remote peer too much control over memory resources local QUIC stack may consume. Quoting RFC 9000 section 9.2.1: ...an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a single packet. Limiting the number of PATCH_CHALLENGE frames to 1 per QUIC packet received helps to reduce heap memory overhead required to process PATH_CHALLENGE frame. Currently QUIC ACKM (ACK-manager) keeps all frames in retransmission buffer until ACK is received. It can be changed such frames which don't need to be ACKed don't need to be kept in retrans buffer, those can be released right after transmission. Fixes CVE-2026-34183 Reviewed-by: Nikola Pajkovsky Reviewed-by: Tomas Mraz MergeDate: Mon Jun 8 14:38:28 2026 (cherry picked from commit fbaa83859c01ad64f497b757aaf51be7d05ed9eb)

Refactor BN_mod() and BN_nnmod() arguments to match documentation

2026-05-29T07:26:29Z

The documentation has this signature for that function: int BN_mod(BIGNUM *r, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx); int BN_nnmod(BIGNUM *r, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx); The implementation, however, had this signature: #define BN_mod(rem, m, d, ctx) BN_div(NULL, (rem), (m), (d), (ctx)) int BN_nnmod(BIGNUM *r, const BIGNUM *m, const BIGNUM *d, BN_CTX *ctx); That pattern alone trips up anyone who associates 'm' with modulus, and and finds themselves using BN_nnmod() incorrectly. This change modifies the argument names to match documentation. Reviewed-by: Matt Caswell Reviewed-by: Tomas Mraz Reviewed-by: Igor Ustinov Reviewed-by: Eugene Syromiatnikov MergeDate: Fri May 29 07:26:33 2026 (Merged from https://github.com/openssl/openssl/pull/31304)

Fix ignored call in ossl_rcu_call when cb item alloc fails

2026-05-18T07:21:08Z

Currently when allocation of cb item fails, the actual cb function is not called. The is used just in hashtable when the cb function frees the old item which result in memory leak. To fix this, the allocation needs to be separated and happen before the assign operation is done. Reviewed-by: Tomas Mraz Reviewed-by: Nikola Pajkovsky MergeDate: Mon May 18 07:21:19 2026 (Merged from https://github.com/openssl/openssl/pull/31165)

Disentangle initial thread-local variable initialization.

2026-05-15T12:47:31Z

New internal routine ossl_thread_init_local implements the platform-specific part of CRYPTO_THREAD_init_local, which is now a wrapper that just does ossl_init_thread then ossl_thread_init_local. This avoids any need for a recursion guard in ossl_init_thread because the static call graph has no cycles: CRYPTO_THREAD_init_local => ossl_init_thread => ossl_thread_init_local => ossl_thread_init_local This avoids UB in pthread semantics, UB from data races, and platform-dependent #ifdefs. fix https://github.com/openssl/openssl/issues/31166 Reviewed-by: Neil Horman Reviewed-by: Tomas Mraz MergeDate: Fri May 15 12:47:37 2026 (Merged from https://github.com/openssl/openssl/pull/31172)

Make SSL_get_stream_write_state() safe for concluded streams

2026-04-28T12:45:50Z

QUIC stack may panic when application calls SSL_get_stream_write_state() on cocluded QUIC stream onject. The sequence of action which leads to NULL pointer dereference is as follows: - application uses SSL_stream_conclude(ssl_stream, 0) to conclude the stream (let remote peer know no to expect more data) - application uses SSL_get_stream_write_state(ssl_stream) to query stream state. If underlying sstream object is gone by the time when SSL_get_stream_wtite_state() is called, then application may see NULL pointer dereference. The underlying sstream object is freed when FIN sent on beahalf of SSL_stream_conclude() is ACKed by remote peer. Original-PR: https://github.com/openssl/openssl/pull/30913 Original-Commit: 211b564f8631 "Make SSL_get_stream_write_state() safe for concluded streams" Reviewed-by: Eugene Syromiatnikov Reviewed-by: Matt Caswell MergeDate: Tue Apr 28 12:41:10 2026 (Merged from https://github.com/openssl/openssl/pull/30960) (cherry picked from commit 847c8065e9dc09283fdfbe751ec515b16da0a4e9)

Removes duplicated __owur.

2026-04-24T09:41:19Z

Reviewed-by: Nikola Pajkovsky Reviewed-by: Eugene Syromiatnikov MergeDate: Fri Apr 24 09:41:20 2026 (Merged from https://github.com/openssl/openssl/pull/30933)

riscv: fix IS_IN_DEPEND_VECTOR range check

2026-04-16T17:04:23Z

The macro checked (ZVX_MIN >= offset) which is equivalent to (offset <= ZVX_MIN), making it true for offsets 0-15 instead of the intended range [ZVX_MIN, ZVX_MAX] = [15, 23]. The practical effect in hwprobe_to_cap() was inverted: - Scalar extensions (ZBA..ZKT, offsets 0-14) were incorrectly treated as vector-dependent and suppressed when VECTOR_CAPABLE was false, preventing their detection via hwprobe. - Vector extensions ZVBC..ZVKSH (offsets 16-23) were not treated as vector-dependent, allowing them to be enabled via hwprobe even when the V extension was absent. Fix by changing >= to <= so the macro correctly tests whether offset falls in [ZVX_MIN, ZVX_MAX]. Signed-off-by: Christoph Müllner Reviewed-by: Eugene Syromiatnikov Reviewed-by: Tomas Mraz MergeDate: Thu Apr 16 17:03:40 2026 (Merged from https://github.com/openssl/openssl/pull/30713) (cherry picked from commit f34f715d03d52face2307dc2c4333c45cd59ef04)

include/openssl/x509_acert.h.in: add extern "C" linkage specification for C++

2026-04-15T12:41:50Z

Fixes: dcee34c8f921 "Add RFC 5755 attribute certificate support" Signed-off-by: Eugene Syromiatnikov Reviewed-by: Nikola Pajkovsky Reviewed-by: Norbert Pocs MergeDate: Wed Apr 15 12:41:53 2026 (Merged from https://github.com/openssl/openssl/pull/30796)