Describe the bug
In TCP mode, link_socket_write_tcp_posix() calls send() exactly once with no retry loop. POSIX does not guarantee that send() on a stream socket writes all requested bytes, i.e. a partial write is a valid outcome. When this occurs, the unwritten tail of the packet is dropped and the TCP framing is permanently broken. Subsequent packets are misframed, decryption fails, and the session restarts.
The caller in forward.c detects the size mismatch and logs a warning, but takes no corrective action (no retry, no connection teardown). The stream is left in a corrupt state.
To Reproduce
We observed the following log sequence on the server side when the peer came under memory pressure:
vpn-seed-server 2026-07-15 20:02:01 vpn-shoot-client-1/tcp6-server:[REDACTED]:45670 Fatal decryption error (process_incoming_link), restarting
vpn-seed-server 2026-07-15 20:02:01 vpn-shoot-client-1/tcp6-server:[REDACTED]:45670 SIGUSR1[soft,decryption-error] received, client-instance restarting
vpn-seed-server 2026-07-15 20:02:01 Closing tun/tap interface
The behavior can also be reproduced deterministically with an LD_PRELOAD shim that intercepts send() and injects a short write. (PR with the reproducer about to follow)
Expected behavior
On a short write, send should be retried for the remaining bytes. The truncation path in forward.c should not leave the stream in an inconsistent state.
Version information
- OS: Alpine Linux
- OpenVPN version: 2.7.3
- Peer OS: Alpine Linux
- Peer OpenVPN version: 2.7.3
Describe the bug
In TCP mode,
link_socket_write_tcp_posix()callssend()exactly once with no retry loop. POSIX does not guarantee thatsend()on a stream socket writes all requested bytes, i.e. a partial write is a valid outcome. When this occurs, the unwritten tail of the packet is dropped and the TCP framing is permanently broken. Subsequent packets are misframed, decryption fails, and the session restarts.The caller in
forward.cdetects the size mismatch and logs a warning, but takes no corrective action (no retry, no connection teardown). The stream is left in a corrupt state.To Reproduce
We observed the following log sequence on the server side when the peer came under memory pressure:
The behavior can also be reproduced deterministically with an LD_PRELOAD shim that intercepts send() and injects a short write. (PR with the reproducer about to follow)
Expected behavior
On a short write, send should be retried for the remaining bytes. The truncation path in forward.c should not leave the stream in an inconsistent state.
Version information