Debian Patches

Status for openvpn/2.6.14-0+deb12u2

Patch Description Author Forwarded Bugs Origin Last update
auth-pam_libpam_so_filename.patch Fix libpam.so filename to /lib/libpam.so.0 in pam plugin=================================================================== Alberto Gonzalez Iniesta <agi@inittab.org> no debian
openvpn-pkcs11warn.patch Warn users about deprecated pkcs11 options=================================================================== Florian Kulzer <florian.kulzer+debian@icfo.es> no debian
CVE-2026-12932.patch Clean up metadata handling in tls_crypt_v2_extract_client_key
This makes the metadata a local variable instead of a member of the
wrap_context struct. Also always ensure that this buffer is freed to
avoid any leak of the metadata buffer.

This touches the check methods. Ensure that they still work as
intended by adding unit tests for both script and age checks.



Backported to 2.6. Since 2.6 is missing the check age checks, these
parts are left out. The unit tests still have some of the infrastructure
to test this part too (creating metadata with specific date) but this
allow the patch to be closer to the 2.7 variant than throwing out that
extra code and reworking it in a more minimal way.		 Arne Schwabe <arne@rfc2549.org> no 2026-06-23
move_log_dir.patch Set default logdir to /var/log/openvpn https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553303 Jörg Frings-Fürst <debian@jff-webhosting.net> not-needed debian 2017-10-03
check-message-id.patch Check message id/acked ids too when doing sessionid cookie checks

This fixes that control packets on a floating client can trigger
creating a new session in special circumstances:

To trigger this circumstance a connection needs to

- starts on IP A
- successfully floats to IP B by data packet
- then has a control packet from IP A before any
data packet can trigger the float back to IP A

and all of this needs to happen in the 60s time
that hmac cookie is valid in the default
configuration.

In this scenario we would trigger a new connection as the HMAC
session id would be valid.

This patch adds checking also of the message-id and acked ids to
discern packet from the initial three-way handshake where these
ids are 0 or 1 from any later packet.

This will now trigger (at verb 4 or higher) a messaged like:

Packet (P_ACK_V1) with invalid or missing SID

instead.

Also remove a few duplicated free_tls_pre_decrypt_state in test_ssl.


Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1184
(backported from commit 518e122b42739b0dbb54e7169a8a3aadb4773125)		 Arne Schwabe <arne@rfc2549.org> no 2025-09-16
CVE-2025-13086.patch Fix memcmp check for the hmac verification in the 3way handshake being inverted

This is a stupid mistake but causes all hmac cookies to be accepted,
thus breaking source IP address validation. As a consequence, TLS
sessions can be openend and state can be consumed in the server from
IP addresses that did not initiate an initial connection.

While at it, fix check to only allow [t-2;t] timeslots, disallowing
HMACs coming in from a future timeslot.




(cherry picked from commit 68ec931e7fb4af11d5ba0d4283df0350083fd373)		 Arne Schwabe <arne@rfc2549.org> no 2025-10-27
CVE-2026-35058.patch 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.


(cherry picked from commit 18270324a5fd43122ca1b8c29b224c5dd5905429)		 Steffan Karger <steffan@karger.me> no 2026-04-12
CVE-2026-40215.patch 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.


(cherry picked from commit b2a15fb84d85790eeae4a2e12b431cbfd0b0302f)		 Arne Schwabe <arne@rfc2549.org> no 2026-04-10
CVE-2026-11771.patch Fix 1-byte buffer overrun on NTLMv2 proxy responses.
An attacker controlling an HTTP proxy (or performing MITM on the
plaintext pre-TLS proxy connection) can trigger a single 0-byte
overrun to a buffer on the stack by sending a crafted NTLM Type
2 challenge response.

The effects of this depend on memory layout, but could possibly lead
to a crashing OpenVPN client.


Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1713
(cherry picked from commit 04309bfe0313c09edd02c29945893b9d7e2ca920)		 Gert Doering <gert@greenie.muc.de> no 2026-06-20
CVE-2026-13122.patch Ensure we only get the session from valid tokens for external-auth

This also improves is_auth_token to check for the correct length and
adds a few unit tests.

This fixes an assertion when a user would send auth token with the
right prefix but overall too short length.



cherry picked from master commit. Adjusted for formatting
differences in 2.6 and kept spelling mistake (old_tsamp instead
of old_stamp) to keep avoid more changes.		 Arne Schwabe <arne@rfc2549.org> no 2026-05-20
CVE-2026-12996.patch Fix ack_write_buf use after free
If the active TLS session has a pending dedicated ACK packet,
tls_multi_process sets to_link to ks->ack_write_buf. If in the same
execution of tls_multi_process, the initializing session reaches the
authenticated stage, the active session will be freed which leaves
to_link.data pointing to freed memory.

This commit extends check_session_buf_not_used so that it also checks
ks->ack_write_buf for all key states.


(cherry picked from master commit)		 Max Fillinger <maximilian.fillinger@sentyron.com> no 2026-05-22
CVE-2026-13698.patch Ensure tls-crypt keys are not setup twice
Commit 82ee2fe4b42d already did this when the session id stayed the same
but forgot the other code path that could also lead to tls-crypt keys to be
setup.

This approach was a bit too fragile as it missed some other code path
that might trigger the same behaviour. This commit changes the logic
to directly infer if the key is already initialised instead of taking
a proxy (like key state as the previous commit did).

The fix in commit 7a6ab5773 (#121, #127) made sure that we do not try
to extract the tls-crypt-v2 key multiple times and made the unit test
basically not work as the extraction was skipped and then could also
not fail anymore. I could work around it in the unit test but improving
tls_wrap_free felt preferable.

(Backported from master commit e287547d85151)		 Arne Schwabe <arne@rfc2549.org> no 2026-06-18
CVE-2026-13117.patch Fix tls_wrap_reneg use after free
When dynamic tls-crypt is active, it is possible for tls_multi_process
to set to_link to session->tls_wrap_reneg.work and later free that
session, leaving to_link.data pointing to freed memory.

This is not caught by the function check_session_buf_not_used because it
checks only tls_wrap, not tls_wrap_reneg. This commit adds that check.

(cherry picked from commit cd536fffdef1f2bd54b3b848bd257917061637e8)		 Max Fillinger <maximilian.fillinger@sentyron.com> no 2026-05-22

All known versions for source package 'openvpn'

Links