netfilter: conntrack: do not auto-delete clash entries on reply
authorFlorian Westphal <fw@strlen.de>
Tue, 25 Aug 2020 22:07:18 +0000 (00:07 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 9 Sep 2020 17:14:19 +0000 (19:14 +0200)
commit3484b664521d5060a911b333d10059af578edde2
tree31f754e1fcfd742b3e56b1ded954ff589b0112da
parent4aa6128188fb3684db58490364af147db8b02020
netfilter: conntrack: do not auto-delete clash entries on reply

[ Upstream commit c46172147ebbeb70094db48d76ab7945d96c638b ]

Its possible that we have more than one packet with the same ct tuple
simultaneously, e.g. when an application emits n packets on same UDP
socket from multiple threads.

NAT rules might be applied to those packets. With the right set of rules,
n packets will be mapped to m destinations, where at least two packets end
up with the same destination.

When this happens, the existing clash resolution may merge the skb that
is processed after the first has been received with the identical tuple
already in hash table.

However, its possible that this identical tuple is a NAT_CLASH tuple.
In that case the second skb will be sent, but no reply can be received
since the reply that is processed first removes the NAT_CLASH tuple.

Do not auto-delete, this gives a 1 second window for replies to be passed
back to originator.

Packets that are coming later (udp stream case) will not be affected:
they match the original ct entry, not a NAT_CLASH one.

Also prevent NAT_CLASH entries from getting offloaded.

Fixes: 6a757c07e51f ("netfilter: conntrack: allow insertion of clashing entries")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/netfilter/nf_conntrack_proto_udp.c
net/netfilter/nft_flow_offload.c