From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Xu Subject: Transport mode xfrm_gro Date: Wed, 6 Dec 2017 14:37:17 +1100 Message-ID: <20171206033717.GA20920@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: Steffen Klassert Return-path: Received: from [128.1.224.119] ([128.1.224.119]:43200 "EHLO ringil.hmeau.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754555AbdLFDhX (ORCPT ); Tue, 5 Dec 2017 22:37:23 -0500 Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-ID: Hi Steffen: I'm looking at the function xfrm_input near the end where it deals with transport mode packets: err = x->inner_mode->afinfo->transport_finish(skb, xfrm_gro || async); if (xfrm_gro) { if (skb->sp) skb->sp->olen = 0; skb_dst_drop(skb); gro_cells_receive(&gro_cells, skb); return err; } This looks wrong because in transport mode, transport_finish is well within its rights to consume and free the skb. For example, IPv4 transport_finish eventually calls xfrm4_rcv_encap_finish which does: if (!skb_dst(skb)) { const struct iphdr *iph = ip_hdr(skb); if (ip_route_input_noref(skb, iph->daddr, iph->saddr, iph->tos, skb->dev)) goto drop; } return dst_input(skb); drop: kfree_skb(skb); return NET_RX_DROP; Whichever path it takes the skb is either gone or belongs to someone else. So why is xfrm_input in the xfrm_gro case trying to reinject the skb into the network stack? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt