Re: [Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Dmitry Melekhov
10.11.2023 11:23, Gert Doering пишет: Hi, On Fri, Nov 10, 2023 at 11:19:58AM +0400, Dmitry Melekhov wrote: OK, now I know what is broken. I have so called multihomed server,  and multihomed udp does not work in 2.6.7. On server with only one external interface everything works OK. Are you us

Re: [Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Gert Doering
Hi, On Fri, Nov 10, 2023 at 11:19:58AM +0400, Dmitry Melekhov wrote: > OK, now I know what is broken. > > I have so called multihomed server,  and multihomed udp does not work in > 2.6.7. > > On server with only one external interface everything works OK. Are you using --multihome in your confi

Re: [Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Gert Doering
Hi, On Fri, Nov 10, 2023 at 10:21:35AM +0400, Dmitry Melekhov wrote: > 10.11.2023 00:56, Yuriy Darnobyt ??: > > The OpenVPN community project team is proud to release OpenVPN 2.6.7. > > something is broken in 2.6.7. it stops passing traffic after several seconds > after connection when ac

Re: [Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Dmitry Melekhov
10.11.2023 10:21, Dmitry Melekhov пишет: 10.11.2023 00:56, Yuriy Darnobyt пишет: The OpenVPN community project team is proud to release OpenVPN 2.6.7. something is broken in 2.6.7. it stops passing traffic after several seconds after connection when acts as server, so I reverted it back to

Re: [Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Dmitry Melekhov
10.11.2023 00:56, Yuriy Darnobyt пишет: The OpenVPN community project team is proud to release OpenVPN 2.6.7. something is broken in 2.6.7. it stops passing traffic after several seconds after connection when acts as server, so I reverted it back to 2.6.6. compiled from sources on ubuntu 2

[Openvpn-devel] OpenVPN 2.6.7 released

2023-11-09 Thread Yuriy Darnobyt
The OpenVPN community project team is proud to release OpenVPN 2.6.7. This is a bugfix release containing security fixes. Security Fixes: * CVE-2023-46850 OpenVPN versions between 2.6.0 and 2.6.6 incorrectly use a send buffer after it has been free()d in some circumstances, causing some free()

[Openvpn-devel] [XS] Change in openvpn[master]: Remove CMake custom compiler flags for RELEASE and DEBUG build

2023-11-09 Thread cron2 (Code Review)
cron2 has submitted this change. ( http://gerrit.openvpn.net/c/openvpn/+/374?usp=email ) Change subject: Remove CMake custom compiler flags for RELEASE and DEBUG build .. Remove CMake custom compiler flags for RELEASE and DEBUG

[Openvpn-devel] [XS] Change in openvpn[master]: Remove CMake custom compiler flags for RELEASE and DEBUG build

2023-11-09 Thread cron2 (Code Review)
cron2 has uploaded a new patch set (#2) to the change originally created by plaisthos. ( http://gerrit.openvpn.net/c/openvpn/+/374?usp=email ) The following approvals got outdated and were removed: Code-Review+2 by flichtenheld Change subject: Remove CMake custom compiler flags for RELEASE and

[Openvpn-devel] [PATCH applied] Re: Remove CMake custom compiler flags for RELEASE and DEBUG build

2023-11-09 Thread Gert Doering
Your patch has been applied to the master branch. commit 753cba211c4752ef13d810b757f1aa7dee89626b Author: Arne Schwabe Date: Tue Nov 7 15:17:55 2023 +0100 Remove CMake custom compiler flags for RELEASE and DEBUG build Acked-by: Frank Lichtenheld Message-Id: <20231107141755.3055

[Openvpn-devel] [PATCH applied] Re: Fix using to_link buffer after freed

2023-11-09 Thread Gert Doering
Third in the series. This is the actual bug fix for the use-after-free leak - looks trivial enough... as Arne says, this part of the code is too full of magic and easy to break. Your patch has been applied to the release/2.6 and master branch. commit 57a5cd1e12f193927c9b7429f8778fec7e04c50a (rel

[Openvpn-devel] [PATCH applied] Re: Double check that we do not use a freed buffer when freeing a session

2023-11-09 Thread Gert Doering
Second in the series. This one is "should we ever do stupid things again, catch us doing so", so not the actual bugfix but belt&suspenders. Your patch has been applied to the release/2.6 and master branch. commit cd4d819c99266fa727c294225cafdb4ae331d02e (release/2.6) commit f09d75083e8d7f6db3d90

[Openvpn-devel] [PATCH applied] Re: Remove saving initial frame code

2023-11-09 Thread Gert Doering
Since this was security related (CVE) it was posted to the security@ list first, and reviewed and ACKed by core team members there. Re-Posting the patches + the commit message here, after 2.6.7 release. I have skimmed the code change and it looks reasonable - and I have subjected this (+ 2/3 and

[Openvpn-devel] [PATCH 3/3] Fix using to_link buffer after freed

2023-11-09 Thread Gert Doering
From: Arne Schwabe When I refactored the tls_state_change method in 9a7b95fda5 I accidentally changed a break into a return true while it should return a false. The code here is extremely fragile in the sense that it assumes that settings a keystate to S_ERROR cannot have any outgoing buffer or

[Openvpn-devel] [PATCH 1/3] Remove saving initial frame code

2023-11-09 Thread Gert Doering
From: Arne Schwabe This code was necessary before the frame/buffer refactoring as we always did relative adjustment to the frame. This also fixes also that previously initial_frame was initialised too early before the fragment related options were initialised and contained 0 for the maximum fram

[Openvpn-devel] [PATCH 2/3] Double check that we do not use a freed buffer when freeing a session

2023-11-09 Thread Gert Doering
From: Arne Schwabe This is a find cases where the session already has planned to send out a packet but encounters some other errors that invalidate the session, setting it to S_ERROR and leaving the buffer behind. This will detect and clear that to_link buffer in that case. Change-Id: I5ffb41be