From 64fae9d82989ede6c92e230c594ab9335c05df8d Mon Sep 17 00:00:00 2001
From: Arne Schwabe <arne@rfc2549.org>
Date: Fri, 10 Apr 2026 16:59:53 +0200
Subject: [PATCH 2/2] Ensure that buffer of freed session are not used
In a race condition an old TLS session could still try to send a packet but
also get replaced by a new session. In this case, the buffer of the new
session is still referenced. Add the check_session_buf_not_used function
to mitigate this problem.
Also make the check if the to_link pointer is in one of the memory
regions a bit better even though this not make a difference with the
way we use these structs. But better safe than sorry.
A better solution to remove the TM_INITIAL state and handle reconnecting
session in their own complete tls_multi is a more involved fix that requires
a lot more refactoring.
CVE: 2026-40215
Reported-By: XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com)
Reported-By: Guannan Wang (wgnbuaa@gmail.com
Reported-By: Zhanpeng Liu (pkugenuine@gmail.com)
Reported-By: Guancheng Li (lgcpku@gmail.com)
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Change-Id: I7c5fa2a7a2563b7a8955d386411f3ceffe5b092f
Private-URL: https://github.com/OpenVPN/openvpn-private-issues/issues/112
Acked-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
---
src/openvpn/ssl.c | 2 ++
1 file changed, 2 insertions(+)
@@ -3290,6 +3290,7 @@ tls_multi_process(struct tls_multi *multi, struct buffer *to_link,
if (i == TM_ACTIVE && ks_lame->state >= S_GENERATED_KEYS
&& !multi->opt.single_session)
{
+ check_session_buf_not_used(to_link, session);
move_session(multi, TM_LAME_DUCK, TM_ACTIVE, true);
}
else
@@ -3363,6 +3364,7 @@ tls_multi_process(struct tls_multi *multi, struct buffer *to_link,
*/
if (TLS_AUTHENTICATED(multi, &multi->session[TM_INITIAL].key[KS_PRIMARY]))
{
+ check_session_buf_not_used(to_link, &multi->session[TM_ACTIVE]);
move_session(multi, TM_ACTIVE, TM_INITIAL, true);
tas = tls_authentication_status(multi);
msg(D_TLS_DEBUG_LOW,
--
2.53.0
Hi, unlike normal "patch on the list (directly or via gerrit), ACK/+2 in public, commit + merge info on the list", patches that carry a CVE tag are handled privately. Whether or not this is always necessary could certainly be debated, but however, in the last releases (2.7.2, 2.6.20, and master) we had two of them. To enable verification that the source has what was discussed and approved, I'll attach the patches plus the relevant commit IDs. commit 64fae9d82989ede6c92e230c594ab9335c05df8d (master) commit 4a2c827c2536aa03a1d6c7cc916689a46c067187 (release/2.7) commit 4472265ea2d18b88bb5f59fb30d4067a0323aff5 (release/2.6) Author: Arne Schwabe <arne@rfc2549.org> Date: Fri Apr 10 16:59:53 2026 +0200 Ensure that buffer of freed session are not used CVE: 2026-40215 commit fa129d7153f7292f7b6f7341601ae97d5c47e36e (master) commit 607e2fcb9cbcff785abfa372c7a59029767b5ed9 (release/2.7) commit 0dc820fe1d0de369d101702151fa06fff0eb360c (release/2.6) Author: Steffan Karger <steffan@karger.me> Date: Sun Apr 12 13:37:56 2026 +0200 tls-crypt-v2: Avoid interpreting opcode as part of WKc CVE: 2026-35058 Details in the commit logs, and on the web https://community.openvpn.net/Security%20Announcements/CVE-2026-40215 https://community.openvpn.net/Security%20Announcements/CVE-2026-35058 both are not of the "the world will end" category, but the ASSERT() one is nasty as you can make a remote server stop itself *iff* tls-crypt-v2 is used, and you can create a sufficiently-malformed packet, signed with a valid tls-crypt-v2 client key. So, you should see that you upgrade *your servers*. Clients are not affected. gert