From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 1E7DC5A0279 for ; Fri, 8 Sep 2023 03:50:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1694137797; bh=1SHU+jlcecWpfsa1b6tXETZzL/YO9++qYZ9mfuyOxlY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gZgzcpT0CWitK9lti4z2HZrGJhek+xTr6xBJfdxHTGPU/yb3lfzcl1aO7sgWJKGXA oIOtOEokRBvBrqyqiE6xN9Rbu6Qm4kXvPvfEtP8jnY0p//ZJwto8y4yelXuqmOCpHV kgBqK5KO2yVsg8sz6mXSr05poDviKnd9F5SMqXK4= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4RhfF10m4rz4xFw; Fri, 8 Sep 2023 11:49:57 +1000 (AEST) From: David Gibson To: passt-dev@passt.top, Stefano Brivio Subject: [PATCH 6/8] tcp: Correctly handle RST followed rapidly by SYN Date: Fri, 8 Sep 2023 11:49:51 +1000 Message-ID: <20230908014953.822952-7-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230908014953.822952-1-david@gibson.dropbear.id.au> References: <20230908014953.822952-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: F5UBXDJZYWOSLTNXARMGLFXCNVOTIZSI X-Message-ID-Hash: F5UBXDJZYWOSLTNXARMGLFXCNVOTIZSI X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: jlesev@gmail.com, David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 --- tcp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tcp.c b/tcp.c index 34c27f0..a1b5a72 100644 --- a/tcp.c +++ b/tcp.c @@ -2337,7 +2337,7 @@ static int tcp_data_from_tap(struct ctx *c, struct tcp_tap_conn *conn, if (th->rst) { conn_event(c, conn, CLOSED); - return p->count - idx; + return 1; } len -= off; @@ -2570,7 +2570,7 @@ int tcp_tap_handler(struct ctx *c, int af, const void *saddr, const void *daddr, if (th->rst) { conn_event(c, conn, CLOSED); - return p->count - idx; + return 1; } if (th->ack && !(conn->events & ESTABLISHED)) -- 2.41.0