Commit a070f75b (master branch only) changed the openvpn_encrypt logic and
now prepends the contents of the work buffer to buf if no encryption is
used (which is the case for tls-auth packets). In that case, the code
would potentially dereference a null-pointer in a memcpy(some-dest, 0, 0)
call. Fortunately, memcpy() inplementations usually do not actually
derefence the src (or dst) pointer for zero-length copies.
And since I'm touching this code now anyway, remove a slightly confusing
jump back to a cleanup label in openvpn_encrypt_aead().
Issue spotted by Daniel Hirche.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1459528980-8304-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11372
Signed-off-by: Gert Doering <gert@greenie.muc.de>
... | ... |
@@ -166,14 +166,14 @@ openvpn_encrypt_aead (struct buffer *buf, struct buffer work, |
166 | 166 |
|
167 | 167 |
dmsg (D_PACKET_CONTENT, "ENCRYPT TO: %s", format_hex (BPTR (buf), BLEN (buf), 80, &gc)); |
168 | 168 |
|
169 |
-cleanup: |
|
170 | 169 |
gc_free (&gc); |
171 | 170 |
return; |
172 | 171 |
|
173 | 172 |
err: |
174 | 173 |
crypto_clear_error(); |
175 | 174 |
buf->len = 0; |
176 |
- goto cleanup; |
|
175 |
+ gc_free (&gc); |
|
176 |
+ return; |
|
177 | 177 |
#else /* HAVE_AEAD_CIPHER_MODES */ |
178 | 178 |
ASSERT (0); |
179 | 179 |
#endif |
... | ... |
@@ -295,7 +295,9 @@ openvpn_encrypt_v1 (struct buffer *buf, struct buffer work, |
295 | 295 |
hmac_start = BPTR(buf); |
296 | 296 |
ASSERT (mac_out = buf_prepend (buf, hmac_ctx_size(ctx->hmac))); |
297 | 297 |
} |
298 |
- buf_write_prepend(buf, BPTR(&work), BLEN(&work)); |
|
298 |
+ if (BLEN(&work)) { |
|
299 |
+ buf_write_prepend(buf, BPTR(&work), BLEN(&work)); |
|
300 |
+ } |
|
299 | 301 |
work = *buf; |
300 | 302 |
} |
301 | 303 |
|