From: Lev Stipakov <>

There is a time frame between allocating peer-id and initializing data
channel key, which is performed on receiving push request.

If a "rogue" data channel packet arrives during that time frame from
another address and  with same peer-id, this would cause client to float
to that new address. This is because:

 - tls_pre_decrypt() sets packet length to zero if
   data channel key has not been initialized, which leads to

 - openvpn_decrypt() returns true if packet length is zero,
which leads to

 - process_incoming_link_part1() returns true, which
calls multi_process_float(), which commits float

Note that problem doesn't happen when data channel key
is initialized, since in this case openvpn_decrypt() returns false.

Fix illegal float by adding buffer length check before calling

This should fix Trac #1272.

Signed-off-by: Lev Stipakov <>
 v2: add comment explaning why nonzero check needed

 src/openvpn/multi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index da0aeeba..37d2a6f2 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2555,7 +2555,8 @@ multi_process_incoming_link(struct multi_context *m, 
struct multi_instance *inst
             orig_buf = c->;
             if (process_incoming_link_part1(c, lsi, floated))
-                if (floated)
+                /* nonzero length means that we have a valid, decrypted packed 
+                if (floated && c->c2.buf.len > 0)
                     multi_process_float(m, m->pending);
2.24.1 (Apple Git-126)

Openvpn-devel mailing list

Reply via email to