diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2023-09-08 11:49:51 +1000 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2023-09-08 09:16:17 +0200 |
commit | f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0 (patch) | |
tree | befadbc2189c4ab0dd465604c35504b56da57c74 /dhcpv6.c | |
parent | 60d3915ea3b07ac0a02aaf73dbf3d99547ff33bc (diff) | |
download | passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar.gz passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar.bz2 passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar.lz passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar.xz passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.tar.zst passt-f984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0.zip |
tcp: Correctly handle RST followed rapidly by SYN
Although it's unlikely in practice, the guest could theoretically
reset one TCP connection then immediately start a new one with the
same addressses and ports, such that we get an RST then a SYN in the
same batch of received packets in tcp_tap_handler().
We don't correctly handle that unlikely case, because when we receive
the RST, we discard any remaining packets in the batch so we'd never
see the SYN. This could happen in either tcp_tap_handler() or
tcp_data_from_tap(). Correct that by returning 1, so that the caller
will continue calling tcp_tap_handler() on subsequent packets allowing
us to process any subsequent SYN.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'dhcpv6.c')
0 files changed, 0 insertions, 0 deletions