From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id C4CC25A0270 for ; Thu, 24 Nov 2022 09:54:29 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4NHsHg5L69z4xN4; Thu, 24 Nov 2022 19:54:23 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1669280063; bh=pVuZAeEjtFtjI9xMXghxTkKolfAzoNTawztjIRzc4Cs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bDMlBfMvWCKuQ3OkZQTa+SfW6rgCq7uAwkfxGQHp9IoIngCIZwSMt/r0Op9G+RBxX QGeGLTEhZTlppQs/klzlSvg//CnH+H+l2Dlo6usGB/yw9s701V7DURq7o5IkI0Wckr ksrrit3H2iYGCehVhMMYmV0xAdahTcj4BenrZeWQ= From: David Gibson To: Stefano Brivio , passt-dev@passt.top Subject: [PATCH 1/4] udp: Fix inorrect use of IPv6 mh buffers in IPv4 path Date: Thu, 24 Nov 2022 19:54:18 +1100 Message-Id: <20221124085421.3027886-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221124085421.3027886-1-david@gibson.dropbear.id.au> References: <20221124085421.3027886-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: RGWAZEH3YXMXTR4LRSRC5STTUEZT2VF4 X-Message-ID-Hash: RGWAZEH3YXMXTR4LRSRC5STTUEZT2VF4 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: David Gibson X-Mailman-Version: 3.3.3 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: udp_sock_handler() incorrectly uses udp6_l2_mh_tap[] on the IPv4 path. In fact this is harmless because this assignment is redundant (the 0th entry msg_hdr will always point to the 0th iov entry for both IPv4 and IPv6 and won't change). There is also an incorrect usage of udp6_l2_mh_tap[] in udp_sock_fill_data_v4. This one can cause real problems, because we'll use stale iov_len values if we send multiple messages to the qemu socket. Most of the time that will be relatively harmless - we're likely to either drop UDP packets, or send duplicates. However, if the stale iov_len we use ends up referencing an uninitialized buffer we could desynchronize the qemu stream socket. Correct both these bugs. The UDP6 path appears to be correct, but it does have some comments that incorrectly reference the IPv4 versions, so fix those as well. Signed-off-by: David Gibson --- udp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/udp.c b/udp.c index ee5c2c5..99f9374 100644 --- a/udp.c +++ b/udp.c @@ -643,7 +643,7 @@ static void udp_sock_fill_data_v4(const struct ctx *c, int n, int *msg_idx, int *msg_bufs, ssize_t *msg_len, const struct timespec *now) { - struct msghdr *mh = &udp6_l2_mh_tap[*msg_idx].msg_hdr; + struct msghdr *mh = &udp4_l2_mh_tap[*msg_idx].msg_hdr; struct udp4_l2_buf_t *b = &udp4_l2_buf[n]; size_t ip_len, buf_len; in_port_t src_port; @@ -717,9 +717,9 @@ static void udp_sock_fill_data_v4(const struct ctx *c, int n, } /** - * udp_sock_fill_data_v4() - Fill and queue one buffer. In pasta mode, write it + * udp_sock_fill_data_v6() - Fill and queue one buffer. In pasta mode, write it * @c: Execution context - * @n: Index of buffer in udp4_l2_buf pool + * @n: Index of buffer in udp6_l2_buf pool * @ref: epoll reference from socket * @msg_idx: Index within message being prepared (spans multiple buffers) * @msg_len: Length of current message being prepared for sending @@ -865,7 +865,7 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref, uint32_t events, if (n <= 0) return; - udp6_l2_mh_tap[0].msg_hdr.msg_iov = &udp6_l2_iov_tap[0]; + udp4_l2_mh_tap[0].msg_hdr.msg_iov = &udp4_l2_iov_tap[0]; for (i = 0; i < (unsigned)n; i++) { udp_sock_fill_data_v4(c, i, ref, -- 2.38.1