aboutgitcodebugslistschat
path: root/dhcpv6.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2023-09-08 11:49:51 +1000
committerStefano Brivio <sbrivio@redhat.com>2023-09-08 09:16:17 +0200
commitf984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0 (patch)
treebefadbc2189c4ab0dd465604c35504b56da57c74 /dhcpv6.c
parent60d3915ea3b07ac0a02aaf73dbf3d99547ff33bc (diff)
downloadpasst-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