summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorFlorian Westphal <fw@strlen.de>2023-01-11 14:42:32 +0100
committerPablo Neira Ayuso <pablo@netfilter.org>2023-01-17 23:00:06 +0100
commitc410cb974f2ba562920ecb8492ee66945dcf88af (patch)
treeaf479529f15ee899a919e0a853b56f45555d8a8f /crypto
parent1f3bd64ad921f051254591fbed04fd30b306cde6 (diff)
downloadlinux-stable-c410cb974f2ba562920ecb8492ee66945dcf88af.tar.gz
linux-stable-c410cb974f2ba562920ecb8492ee66945dcf88af.tar.bz2
linux-stable-c410cb974f2ba562920ecb8492ee66945dcf88af.zip
netfilter: conntrack: handle tcp challenge acks during connection reuse
When a connection is re-used, following can happen: [ connection starts to close, fin sent in either direction ] > syn # initator quickly reuses connection < ack # peer sends a challenge ack > rst # rst, sequence number == ack_seq of previous challenge ack > syn # this syn is expected to pass Problem is that the rst will fail window validation, so it gets tagged as invalid. If ruleset drops such packets, we get repeated syn-retransmits until initator gives up or peer starts responding with syn/ack. Before the commit indicated in the "Fixes" tag below this used to work: The challenge-ack made conntrack re-init state based on the challenge ack itself, so the following rst would pass window validation. Add challenge-ack support: If we get ack for syn, record the ack_seq, and then check if the rst sequence number matches the last ack number seen in reverse direction. Fixes: c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets only") Reported-by: Michal Tesar <mtesar@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions