Commit 55ccc0

2026-04-22 20:58:00 uddr: CVE-2026-35058
/dev/null .. Security Announcements/CVE-2026-35058.md
@@ 0,0 1,40 @@
+ # CVE-2026-35058 - fix server ASSERT() on receiving a suitably malformed packet with a valid tls-crypt-v2 key
+
+ tls-crypt-v2: Avoid interpreting opcode as part of WKc
+
+ The buffer we pass to tls_crypt_v2_extract_client_key contains the
+ entire received control channel packet. We should skip the opcode before
+ trying to read WKC.
+
+ This logic error is a second bug behind the XlabAI finding, next too the
+ too-strict ASSERT in tls_crypt_unwrap.
+
+ Also remove a too strict ASSERT in tls_crypt_unwrap. We already check
+ a few lines later for a too short packet and return a proper error
+ ("packet too short").
+
+ XlabAI found a way of triggering this ASSERT that requires a tls-crypt-v2
+ client key that has a specific property (a specific byte need to have a
+ specific value, about 1/256 probability). If an attacker can get hold of
+ such a tls-crypt-v2 client key or observe a handshake using such a key,
+ the attacker can trigger the ASSERT, crashing the server. Setups that do
+ not use tls-crypt-v2 are not affected.
+
+ Independently, Cisco Talos reported a way to trigger this ASSERT with any
+ tls-crypt-v2 key but this requires the attacker to be also in possession
+ of the private key part of the tls-crypt-v2 client key or to inject packet
+ into a live session of a client session.
+
+ OpenVPN version 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1 are affected. This is fixed in version 2.6.20 and 2.7.2.
+
+ CVE Record: [CVE-2026-35058](https://www.cve.org/CVERecord?id=CVE-2026-35058)
+
+ Github: [OpenVPN/openvpn-private-issues#111](https://github.com/OpenVPN/openvpn-private-issues/issues/111)
+
+ Release notes: [openvpn-2.7.2](https://community.openvpn.net/ReleaseHistory#openvpn-272-released-22-april-2026) [openvpn-2.6.20](https://community.openvpn.net/ReleaseHistory#openvpn-2620-released-22-april-2026)
+
+ 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)
+ Reported-By: Emma Reuter of Cisco ASIG (TALOS-2026-2381)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9