Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp5215354iog; Wed, 22 Jun 2022 14:50:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uF2Ss4iMeaZvfC/Tcdf+5I0WCpiBkuqQwAImqFBT/Il0Neo9uB0FSZRa/DgNvKWH8qRsc/ X-Received: by 2002:a05:6a00:1481:b0:51c:4e9a:f618 with SMTP id v1-20020a056a00148100b0051c4e9af618mr38232044pfu.43.1655934614017; Wed, 22 Jun 2022 14:50:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655934614; cv=none; d=google.com; s=arc-20160816; b=AUCwjTCcQvJtBolX2R0XC40EsaSjcgVDeIxtx2smcC4MWUy3KhL6HdSyA5xOYxmP6/ 9CEixgzLoPEaG3z+OdBAztrTJvA04quqQmKU20eS+gugbwcQ8Q22jJD84KX0MqCHPJAn 93YljIDbo9nOtsjcczUWHjmu20l/tumk/BoybohKQ8K1wNNhhMzGts+mLgNXzbBrXsfP CoEnwQxiInDWlpNK2izFfmMmHK4tFWnY//oLGfuGb+kWoT/9vTASbdgi/vBFpbTYJlr5 sV042z1azXozldrFnqsN1dzEzZCicxC7cpDe0iGXyGEQK1h7bACpmdwSJ1fOkJH1DKhx HYog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:to:content-language:cc:user-agent:mime-version:date :message-id; bh=Pkx9CLqk7LX5VcPLDOaopQIyIyHhl9NO6tn00KUjWxA=; b=fZ+TGggj70XTuS8aQI6NjSaPVq6YiGTilwx3CkkDHi36g1SwpIAoLPZmEOgRFPXvqw bgvHqMHsKi3hW89RIjvKrfYUzwehaiMgt7gSbzeedtqV9R+CB87VCiUt0YjA2EbdKyEK gQ6iDO+f2mKJVUosrvOzJJyLCe7sigugmBrPQBUmAvCzVc0z23IhzmcmjlPc7Lm3DqqH B9Ztqbc9RNmF8U8zNkidNdzbL8I174IzTlt4I4q2W98K/m8i386leB2XcjtVBAhFBDO1 j/310Ny5xvz/H8I7XAFDR/1Dxi/JzYSgtIC3ZYrjgnz5ovct2kTBMy7rl5Ta1TwB16kx vazA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e6-20020a170902ef4600b0015e583f7b54si29637942plx.14.2022.06.22.14.50.00; Wed, 22 Jun 2022 14:50:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347203AbiFVVM7 (ORCPT + 99 others); Wed, 22 Jun 2022 17:12:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344588AbiFVVMz (ORCPT ); Wed, 22 Jun 2022 17:12:55 -0400 Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::222]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D96BAB4; Wed, 22 Jun 2022 14:12:51 -0700 (PDT) Received: (Authenticated sender: i.maximets@ovn.org) by mail.gandi.net (Postfix) with ESMTPSA id 1ABC64000B; Wed, 22 Jun 2022 21:12:47 +0000 (UTC) Message-ID: Date: Wed, 22 Jun 2022 23:12:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Cc: i.maximets@ovn.org, Steffen Klassert , Herbert Xu , Florian Westphal , netdev , "David S. Miller" , dev@openvswitch.org, LKML , Jakub Kicinski , Paolo Abeni Content-Language: en-US To: Eric Dumazet References: <20220619003919.394622-1-i.maximets@ovn.org> <20220622102813.GA24844@breakpoint.cc> <068ad894-c60f-c089-fd4a-5deda1c84cdd@ovn.org> <673a6f2b-dab2-e00f-b37c-15f8775b2121@ovn.org> From: Ilya Maximets Subject: Re: [PATCH net] net: ensure all external references are released in deferred skbuffs In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/22/22 21:27, Eric Dumazet wrote: > On Wed, Jun 22, 2022 at 9:04 PM Eric Dumazet wrote: >> >> On Wed, Jun 22, 2022 at 8:19 PM Ilya Maximets wrote: >>> >>> On 6/22/22 19:03, Eric Dumazet wrote: >>>> On Wed, Jun 22, 2022 at 6:47 PM Eric Dumazet wrote: >>>>> >>>>> On Wed, Jun 22, 2022 at 6:39 PM Eric Dumazet wrote: >>>>>> >>>>>> On Wed, Jun 22, 2022 at 6:29 PM Eric Dumazet wrote: >>>>>>> >>>>>>> On Wed, Jun 22, 2022 at 4:26 PM Ilya Maximets wrote: >>>>>>>> >>>>>>>> On 6/22/22 13:43, Eric Dumazet wrote: >>>>>>> >>>>>>>> >>>>>>>> I tested the patch below and it seems to fix the issue seen >>>>>>>> with OVS testsuite. Though it's not obvious for me why this >>>>>>>> happens. Can you explain a bit more? >>>>>>> >>>>>>> Anyway, I am not sure we can call nf_reset_ct(skb) that early. >>>>>>> >>>>>>> git log seems to say that xfrm check needs to be done before >>>>>>> nf_reset_ct(skb), I have no idea why. >>>>>> >>>>>> Additional remark: In IPv6 side, xfrm6_policy_check() _is_ called >>>>>> after nf_reset_ct(skb) >>>>>> >>>>>> Steffen, do you have some comments ? >>>>>> >>>>>> Some context: >>>>>> commit b59c270104f03960069596722fea70340579244d >>>>>> Author: Patrick McHardy >>>>>> Date: Fri Jan 6 23:06:10 2006 -0800 >>>>>> >>>>>> [NETFILTER]: Keep conntrack reference until IPsec policy checks are done >>>>>> >>>>>> Keep the conntrack reference until policy checks have been performed for >>>>>> IPsec NAT support. The reference needs to be dropped before a packet is >>>>>> queued to avoid having the conntrack module unloadable. >>>>>> >>>>>> Signed-off-by: Patrick McHardy >>>>>> Signed-off-by: David S. Miller >>>>>> >>>>> >>>>> Oh well... __xfrm_policy_check() has : >>>>> >>>>> nf_nat_decode_session(skb, &fl, family); >>>>> >>>>> This answers my questions. >>>>> >>>>> This means we are probably missing at least one XFRM check in TCP >>>>> stack in some cases. >>>>> (Only after adding this XFRM check we can call nf_reset_ct(skb)) >>>>> >>>> >>>> Maybe this will help ? >>> >>> I tested this patch and it seems to fix the OVS problem. >>> I did not test the xfrm part of it. >>> >>> Will you post an official patch? >> >> Yes I will. I need to double check we do not leak either the req, or the child. >> >> Maybe the XFRM check should be done even earlier, on the listening socket ? >> >> Or if we assume the SYNACK packet has been sent after the XFRM test >> has been applied to the SYN, >> maybe we could just call nf_reset_ct(skb) to lower risk of regressions. >> >> With the last patch, it would be strange that we accept the 3WHS and >> establish a socket, >> but drop the payload in the 3rd packet... > > Ilya, can you test the following patch ? Tested with OVS and it works fine, the issue doesn't appear. Still didn't test the xfrm part, as I'm not sure how. > I think it makes more sense to let XFRM reject the packet earlier, and > not complete the 3WHS, > if for some reason this happens. OK. However, now the patch looks more like two separate fixes. > > Thanks ! > > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c > index fe8f23b95d32ca4a35d05166d471327bc608fa91..da5a3c44c4fb70f1d3ecc596e694a86267f1c44a > 100644 > --- a/net/ipv4/tcp_ipv4.c > +++ b/net/ipv4/tcp_ipv4.c > @@ -1964,7 +1964,10 @@ int tcp_v4_rcv(struct sk_buff *skb) > struct sock *nsk; > > sk = req->rsk_listener; > - drop_reason = tcp_inbound_md5_hash(sk, skb, > + if (!xfrm4_policy_check(sk, XFRM_POLICY_IN, skb)) > + drop_reason = SKB_DROP_REASON_XFRM_POLICY; > + else > + drop_reason = tcp_inbound_md5_hash(sk, skb, > &iph->saddr, &iph->daddr, > AF_INET, dif, sdif); > if (unlikely(drop_reason)) { > @@ -2016,6 +2019,7 @@ int tcp_v4_rcv(struct sk_buff *skb) > } > goto discard_and_relse; > } > + nf_reset_ct(skb); > if (nsk == sk) { > reqsk_put(req); > tcp_v4_restore_cb(skb);