Skip to content

netfilter: nf_conntrack incorrectly checking SEQ on syn-ack packets

Florian Westphal requested to merge fwestpha/centos-stream-9-fw:bz2051973 into main

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2051973 Tested: with packetdrill reproducer from bugzilla Conflicts: none

Netfilter assumed that a second syn-ack must be a retransmit of the first syn-ack seen. This isn't correct, first syn-ack might be severely delayed answer to an earlier connection attempt.

When this happens, the connection can never complete, first syn-ack is marked invalid and dropped by the ruleset, the correct syn-ack is then checked against the bogus state taken from the first syn-ack:

0.1 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress) 0.1 > S 0:0(0) win 29200 <mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 8>

// bogus/outdated synack: invalid ack value, conntrack marks it as // invalid (as expected). 0.1 < S. 145824453:145824453(0) ack 643160523 win 240 <mss 1460,nop,nop,TS val 1 ecr 1,nop,wscale 0>

// syn retransmit 1.125 > S 0:0(0) win 29200 <mss 1460,sackOK,TS val 1015 ecr 0,nop,wscale 8>

// correct synack, but its considered invalid too as its checked vs. // data taken from the first syn-ack: +0 < S. 162602410:162602410(0) ack 1 win 250 <mss 1460,nop,nop,TS val 1 ecr 1,nop,wscale 0>

First patch is code refactoring, second patch is the fix: re-init state for all retransmitted syn-acks.

Signed-off-by: Florian Westphal fwestpha@redhat.com

Merge request reports