Before this patch, if TCP state is < TIME_WAIT, we skip this logic.
Along time, we got new states over the TIME_WAIT value, such as
SYN_SENT2, RETRANS and UNACK, that can trigger this conntrack entry
reset, however this check was never updated.

My understanding is that we should only exercise the conntrack reset
codepath if the existing packet is triggering a transition to SYN_SENT
state while we were in TIME_WAIT or CLOSE states.

Signed-off-by: Pablo Neira Ayuso <pa...@netfilter.org>
---
While reviewing TCP tracking code, I noticed this. This is just narrowing
down this codepath so it only works with TIME_WAIT and CLOSE states.

 net/netfilter/nf_conntrack_proto_tcp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_proto_tcp.c 
b/net/netfilter/nf_conntrack_proto_tcp.c
index e97cdc1cf98c..c765d83db574 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -827,7 +827,8 @@ static int tcp_packet(struct nf_conn *ct,
 
        switch (new_state) {
        case TCP_CONNTRACK_SYN_SENT:
-               if (old_state < TCP_CONNTRACK_TIME_WAIT)
+               if (old_state != TCP_CONNTRACK_TIME_WAIT &&
+                   old_state != TCP_CONNTRACK_CLOSE)
                        break;
                /* RFC 1122: "When a connection is closed actively,
                 * it MUST linger in TIME-WAIT state for a time 2xMSL
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to