| Message ID | 20260809213007.3446185-4-adolf.belka@ipfire.org |
|---|---|
| State | Staged |
| Commit | a26209adae494a5dabc4c8345da91e12b0896ad1 |
| Headers |
Return-Path: <development+bounces-2518-patchwork=ipfire.org@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4hJB1r2bDWz3wqM for <patchwork@web04.haj.ipfire.org>; Sun, 09 Aug 2026 21:32:48 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail02.haj.ipfire.org", Issuer "YE1" (not verified)) by mail01.ipfire.org (Postfix) with ESMTPS id 4hJB1h1GWlz75F for <patchwork@ipfire.org>; Sun, 09 Aug 2026 21:32:40 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4hJ9zS61yZz37BN for <patchwork@ipfire.org>; Sun, 09 Aug 2026 21:30:44 +0000 (UTC) X-Original-To: development@lists.ipfire.org Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4hJ9zQ29fqz2xQT for <development@lists.ipfire.org>; Sun, 09 Aug 2026 21:30:42 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4hJ9zG0wDlz2Jt; Sun, 09 Aug 2026 21:30:34 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1786311034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=94LIIRoEz6d2nAmSU4pRw6ModBalaF3z/DY+34cDTmE=; b=UiqUPxruvPz6wM4XdpKTl+Z9Wc0K/pBHLGgWF7v3iXoL+tWQ7Y9qnOty8CPo4HcjtGJMZa cw8zWVPnADNwxQAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1786311034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=94LIIRoEz6d2nAmSU4pRw6ModBalaF3z/DY+34cDTmE=; b=a9dGprU7ZXnXolomVOflpPrbiFrFk0Uil1iTXjqtNLpm3jTnBqmRnqIVUO/P6dPxOdwROO 3MzPQBDbC9dgx6tnEAqYqEX0dgRU449DRv6/JOcDt00I9bRfKo7csoLuyDS1+Bgx8VRRha CYKriXQKzXW5Dc38XsuFZvdIW1RtDstiMblH/wMw/WTfwoWv69+MpihzZb+8DDHT3Vptp0 hHJJ6fgQBfjtsBpbNaGET0ikrfu/FW6CjVFi1wtjaS/VAE0orHrkliNEHxYc27XwTuNXmk Kczl2LJsDYkLGQftHCaGg6yj46q5QZQpfN5e98U/xCIhnD189JtuFdy4DWqnvg== From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Cc: Adolf Belka <adolf.belka@ipfire.org> Subject: [PATCH] openvpn: Update to version 2.7.6 Date: Sun, 9 Aug 2026 23:30:06 +0200 Message-ID: <20260809213007.3446185-4-adolf.belka@ipfire.org> In-Reply-To: <20260809213007.3446185-1-adolf.belka@ipfire.org> References: <20260809213007.3446185-1-adolf.belka@ipfire.org> Precedence: list List-Id: <development.lists.ipfire.org> List-Subscribe: <https://lists.ipfire.org/>, <mailto:development+subscribe@lists.ipfire.org?subject=subscribe> List-Unsubscribe: <https://lists.ipfire.org/>, <mailto:development+unsubscribe@lists.ipfire.org?subject=unsubscribe> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development+help@lists.ipfire.org?subject=help> Sender: <development@lists.ipfire.org> Mail-Followup-To: <development@lists.ipfire.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit |
| Series |
openvpn: Update to version 2.7.6
|
|
Commit Message
Adolf Belka
9 Aug 2026, 9:30 p.m. UTC
- Update from version 2.7.4 to 2.7.6
- No change in rootfile
- 2 CVE Fixes from 2.7.6 and 7 CVE Fixes from 2.7.5
- Changelog
2.7.6
Security fixes:
openvpnserv (windows): better scrutinize command line passed in
from the control socket to openvpn. This would lead to circumventing
admin restrictions on allowed openvpn config directories (but never
to "read files the user has no permissions for") (CVE-2026-63649)
Bug found by 章鱼哥 (www.aipyaipy.com)
dco: make key state desync recoverable
This was reported as a "with suitable timing, a key-update de-sync between
OpenVPN and the kernel could trigger an ASSERT()", and was initially
handled as security report. It turned out to be not exploitable, but the
state machine was not very robust and so the opportunity was used to
improve the code.
Bug found by 章鱼哥 (www.aipyaipy.com)
make --x509-username-field work with mbedTLS.
In very particular setups, together with a CA creating matching certificates,
this could lead to unintentionally permitting a certificate that should
not have. This is why this was considered a (low-prio) security bug and a
CVE ID was assigned (CVE-2026-63650)
Bug found by 章鱼哥 (www.aipyaipy.com)
User-visible Changes:
if --dev is not specified, default to --dev tun - so for the
tun case, this option can now be left out of the openvpn config.
--ping and --keepalive settings are now limited to 24 hours
maximum - the primary reason for that is to avoid lots of extra code
in the DCO kernel to handle arbitrarily large values without overflowing
32 bit integers. 24h is considered much higher than any reasonable use.
The TCP_NODELAY socket flag is now "always on". The --tcp-nodelay
option is kept, because setting it on a p2mp server also enables pushing
of socket-flags TCP_NODELAY to clients, which might not have this
code change yet.
Remove --providers from --help output on mbedTLS builds.
Bugfixes:
refuse incoming HARD RESET packets with a sequence ID != 0
(this is basically making an OpenVPN server ignore and log a
"should never happen" client-side misbehaviour, which could lead to
TLS handshake establishment failures in p2p TLS setups)
correctly calculate packet id size if epoch packet format is in use -
this was off by 4, for connections openvpn 2.7+ to openvpn 2.7+,
exceeding "mssfix mtu" headroom by those 4 bytes
(Github: OpenVPN/openvpn#1074)
correct minimum packet length check for 802.1q tagged packets
(Github: OpenVPN/openvpn#1044).
This was also reported (twice) as a security bug, as technically
OpenVPN with --client-nat would read and write up to 4 bytes
"after the end of the packet" - but due to the OpenVPN packet buffer
layouts, which are always full-frame-sized this is fully safe and has
no adverse consequences.
2.7.5
Security fixes:
openvpnserv (windows): fix DNS SearchList state pollution on (dis)connect.
specific combinations of --dns config entries plus local DNS config
could lead to corruption of pre-openvpn DNS config (CVE-2026-13379)
Bug found by 章鱼哥 (www.aipyaipy.com).
Fix use-after-free bug in ack_write_buf(), triggerable by a well-timed
sequence of control channel + authentication packets (CVE-2026-12996)
Bug found by multiple researchers:
章鱼哥 (www.aipyaipy.com)
Haiyang Huang
Haruki Oyama (Waseda University)
Fix use-after-free bug in tls_wrap_reneg(), triggerable by suitable
sequence of dynamic tls-crypt control-channel packets (CVE-2026-13117)
Bug found by multiple researchers:
Trace37 Labs (github.com/trace37labs)
Haiyang Huang
Fix server crash on reception of suitably malformed auth-token, if
--auth-gen-token external-auth is active (CVE-2026-13122)
Bug found by Haiyang Huang.
Fix memory-leak in tls-crypt-v2 client key handling that could lead
to out-of-memory situations and subsequent server crashes (CVE-2026-12932)
Bug found by Valton Tahiri.
Fix possible 1-byte buffer overrun on NTLMv2 proxy responses.
(CVE-2026-11771)
Bug found by Tristan Madani (@TristanInSec).
Fix another memory leak on reception of suitable tls-crypt-v2 packets
that could lead to an out of memory situation and server crash
(CVE-2026-13698)
Bug found by Max Fillinger. Overlaps with a report
from Valton Tahiri that we believe to
be fixed by this bugfix as well.
Bugfixes:
Windows: fix plugin trusted-dir check prefix bypass
(this fixes a bug in the path checking logic we do on Windows for
"is loading a plugin from this path allowed?", but since we could
not find a way to exploit this unless starting with admin privs or
a social engineering attack, not classified as a security fix)
Windows: openvpnserv: rework ConvertItfDnsDomains and tests
(this fixes a buffer overread that is not exploitable and as such
not classified as security fix)
options: fix use-after-free of DNS options on client connect
(using suitable --dns or --dhcp-option DNS options in a server
config - not pushed, but applying to the server itself - triggers a
double free() and use-after-free condition, possibly crashing the
server) (Github: OpenVPN/openvpn#1060)
dns: Fix memory leak in dns_server_addr_parse, if too many server
addresses are configured (Github: OpenVPN/openvpn#1055)
improve multi-socket event handling further - multiple open UDP sockets
with concurrent traffic could lead to inefficient processing, and the
old code was also very hard to follow.
(This was initially triggered by a report from Joshua Rogers using ZeroPath,
but turned out to be "just bad code" not a security vulnerability)
Null-terminate tls-crypt client keys when testing - non-exploitable
strlen() on a buffer that is not null-terminated
mudp: send HMAC reset reply synchronously
this fixes a bug where multiple incoming tls-crypt-v2 RESET packets
on different sockets could end up overwriting each other's control
structures, leading to initial handshake packets (HMAC reset reply)
being sent to the wrong client IP, or on a non-suitable socket
("v4 packet on a v6 socket"). Since the overall flow here is stateless
by nature, do not artificially create state by creating elaborate
queues, just send-or-drop.
fix port-share and multi-socket interaction - port-share needs TCP
listeners, but the check was wrong. So "as long as any of the listening
sockets is TCP, port-share can be used" (Github: OpenVPN/openvpn#1027)
Ensure pushed tun-mtu is no lower than TUN_MTU_MIN - this fixes a bug
where a server can push a suitable combination of options and make the
client ASSERT().
(Reported as security issue by Haiyang Huang,
but it was decided that the server always has means to make the client
"not function properly", and it can not be exploited beyond that)
Windows: socket: assert buffer length before reading prepended sockaddr
family - a misbehaviour in the windows DCO driver could trigger an
overread in the userland client. No such bug exists, which this was
not treated as a security vulnerability
Documentation improvements:
improve documentation for --float (Github: OpenVPN/openvpn#358)
add documentation for --preresolve (Github: OpenVPN/openvpn#532)
impove documentation around DNS config (Github: OpenVPN/openvpn#937)
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
lfs/openvpn | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lfs/openvpn b/lfs/openvpn index 474ea5f39..010c3a375 100644 --- a/lfs/openvpn +++ b/lfs/openvpn @@ -24,7 +24,7 @@ include Config -VER = 2.7.4 +VER = 2.7.6 THISAPP = openvpn-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 8957cde4fbf04a8108e9cb19720ed089275055a96a1accf7a466786606e2b9dc93a0151eb50a8fcfa982b66efc3e699ebd1bd0fdd1fb0b6d810b1f8e6815c190 +$(DL_FILE)_BLAKE2 = 0cf4f6c7337ef3e31cb6f261423863b86fedcaaa69272d26811f4066afcece873ccebca167cb5e9f37bc474ccbbad7f71effc0678b98ed52864a96351a8cc3f0 install : $(TARGET)