From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 67196A04FD; Mon, 4 Apr 2022 08:22:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5750B40698; Mon, 4 Apr 2022 08:22:35 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id DE2EB4068C; Mon, 4 Apr 2022 08:22:33 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v1] gro: bug fix in identifying 0 length tcp packets Date: Mon, 4 Apr 2022 08:22:31 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86F9C@smartserver.smartshare.dk> In-Reply-To: <20220403115031.59632-1-kumaraparamesh92@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v1] gro: bug fix in identifying 0 length tcp packets Thread-Index: AdhHURJHeQ+zTfQWTSq0g1YPoC1XDQAmqMDw References: <20220403115031.59632-1-kumaraparamesh92@gmail.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Kumara Parameshwaran" , Cc: , , "Kumara Parameshwaran" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Kumara Parameshwaran [mailto:kumaraparamesh92@gmail.com] > Sent: Sunday, 3 April 2022 13.51 >=20 > As the minimum Ethernet frame size is 64 bytes, a 0 length > tcp payload without tcp options would be 54 bytes and hence > there would be padding. So it would be incorrect to use the > packet length to determine the tcp data length. >=20 > Fixes: 1e4cf4d6d4fb ("gro: cleanup") > Cc: stable@dpdk.org >=20 > Signed-off-by: Kumara Parameshwaran > --- > v1: > Do not use packet length to determine the tcp data length as > the packet length could have padded bytes. This would lead > to addition of 0 length tcp packets into the GRO layer when > there ethernet fram is padded. > lib/gro/gro_tcp4.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) >=20 > diff --git a/lib/gro/gro_tcp4.c b/lib/gro/gro_tcp4.c > index 7498c66..45e3f48 100644 > --- a/lib/gro/gro_tcp4.c > +++ b/lib/gro/gro_tcp4.c > @@ -198,7 +198,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > struct rte_tcp_hdr *tcp_hdr; > uint32_t sent_seq; > int32_t tcp_dl; > - uint16_t ip_id, hdr_len, frag_off; > + uint16_t ip_id, frag_off; > uint8_t is_atomic; >=20 > struct tcp4_flow_key key; > @@ -217,7 +217,6 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > eth_hdr =3D rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *); > ipv4_hdr =3D (struct rte_ipv4_hdr *)((char *)eth_hdr + pkt- > >l2_len); > tcp_hdr =3D (struct rte_tcp_hdr *)((char *)ipv4_hdr + pkt->l3_len); > - hdr_len =3D pkt->l2_len + pkt->l3_len + pkt->l4_len; >=20 > /* > * Don't process the packet which has FIN, SYN, RST, PSH, URG, > ECE > @@ -229,7 +228,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > * Don't process the packet whose payload length is less than or > * equal to 0. > */ > - tcp_dl =3D pkt->pkt_len - hdr_len; > + tcp_dl =3D rte_be_to_cpu_16(ipv4_hdr->total_length) - (pkt->l3_len > + pkt->l4_len); > if (tcp_dl <=3D 0) > return -1; >=20 > -- > 2.7.4 >=20 Please confirm that this does not introduce a buffer overrun regarding = malformed packets, e.g. a small packet with ipv4_hdr->total_length set = to 65000. I haven't looked at the patch in context, so my concern may be = irrelevant. -Morten