Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1997377rwi; Tue, 11 Oct 2022 03:30:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6AygEIa4u/QbAbkbNW2nZEFJU1cMJIZwk2n/ebVFPOvF79+lgjonDbKebB39u19B+vCQX6 X-Received: by 2002:a05:6402:28ca:b0:43b:5235:f325 with SMTP id ef10-20020a05640228ca00b0043b5235f325mr21968940edb.320.1665484245205; Tue, 11 Oct 2022 03:30:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665484245; cv=none; d=google.com; s=arc-20160816; b=ua4U3/UeJuiKTS3KF8ngsTrp0IEttNS479ybzH618//TP0c/NdOEJl6suT3VVIOS+r uaYSi2XV+TNcnoYiECIEZKJYfkGNVWStMCKvOW5K4uExI/Q1unz/kDzMsMR9vq2ZjAGn qr/AQDCBXKA7YUWGba5QhxufH9fguU2c13Qm/D2pnf6zEo9v+dg6sZqLuM10227d/J8F SSMiE17c+M2KvoQikYdlh2cMzPGuqKuoUYmawHR06ZTSIB1r2n/4yw3kSzLdqtsfQde4 gstHtN3LLprQj+8y9yGNQAbK+3hYKEUJlMVFhB+1iTb4U4gbFJXLAPH1JpTgo2W4vYYW 5vSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=XiLYSpf3q8G+5FzkO8Bm2R5lAQ9B/J9Zd9PiR+9O0jg=; b=e/r8KiC3hwHoF6DYzM71/wew6rUXvKk7sUIe2R1IxbyVq+9YcY6IgDKM/UDDp3vR4x UQhx8QpMSchEQSq+8e+jRwE+bF6HnU8i4z9CFtqsmN6lx3wUpABtb2vAgkE6uM0pTEmT dHdhJYiQsJF4DE+psNYXTuGdtwjkrRFhUcwdoEBnmbRyk08P3IBWF8ghRbQ+uTskSp9G RWHSUL7CA0i6idB4lN53OAc9Eq28AlS4EHRoKA53BWn8aUkZpzoDOTUmJM22bALpgCkf OHk0qvdxKWsESAR3O/n6aWVnET5XL2jIEQAeZdogfSoEypubRwJimdLU/vjK6dS9NR6g FAjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bHcZKrL3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ga6-20020a1709070c0600b0076f061ffab4si10856641ejc.51.2022.10.11.03.30.16; Tue, 11 Oct 2022 03:30:45 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bHcZKrL3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229908AbiJKKCY (ORCPT + 99 others); Tue, 11 Oct 2022 06:02:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229932AbiJKKBj (ORCPT ); Tue, 11 Oct 2022 06:01:39 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C4E38D0D5 for ; Tue, 11 Oct 2022 03:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665482447; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XiLYSpf3q8G+5FzkO8Bm2R5lAQ9B/J9Zd9PiR+9O0jg=; b=bHcZKrL3YhMArKJF6CRagcN8YUbVbp68FktfNhQWwXY1nwlopg0w0s8skH7Rby3AYyL9Yu oXxzscOqlxetGTAt9p3UEHjp7uhxsKHcs2i7WOLVjxrJw3Pg/n0WRYPGtkEZbgBR+E+YBk zRI/5v1HZn8Ua4rMT3eJVdkOmGrMOOI= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-628-5k6XVnkLMx2BEdoU6A-gXQ-1; Tue, 11 Oct 2022 06:00:46 -0400 X-MC-Unique: 5k6XVnkLMx2BEdoU6A-gXQ-1 Received: by mail-qk1-f198.google.com with SMTP id bs30-20020a05620a471e00b006ed2a84071bso3502206qkb.0 for ; Tue, 11 Oct 2022 03:00:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XiLYSpf3q8G+5FzkO8Bm2R5lAQ9B/J9Zd9PiR+9O0jg=; b=0n0c2BJ+Fal69a82smqUHwhGhiEcDXt9nXeX1L4Lh9ABmUmKziD1Iqp0m7ygcThHu7 9VWIA+q9cBeY4k/+7lsjw5M104x5kPcxUjfoz4gfb3bHyrUWAAL4vPME4gGHzyWQU+69 VYfpXVuZS7ilOly2QHNabKy9aYFWZfoXafpNqZ0qMcQirmjOq/GX6q5BdWwmtnRz7fJT luFxASLkXFWLNergBK1p+PhD9W8uqti8WKefvywnp5lji6ejWQ1R11lI0JSoVvVFQwVQ fs+Iz9MV+rsA2RMf/k9YXbl5QUSCv6lky9HiFwRQWr+IeaAQjXVWqMbNXbz6voYwGUrt FO1w== X-Gm-Message-State: ACrzQf24+11VPVsbV4EHTz+wAs59Et15ISsAyNUZkHsmVJC0FJXWVDGo 3bk3UJiRcrI3W7yoa0I7SUgLUbtIF7dQ6xJgsQ4cM66eJAB/U3HI1d8dzj+HcDCe4HMJbkGz06t TgtX/sfl91/FY/hY9cbIFthDv X-Received: by 2002:a05:6214:e4a:b0:4b1:d684:f72f with SMTP id o10-20020a0562140e4a00b004b1d684f72fmr18137824qvc.3.1665482445896; Tue, 11 Oct 2022 03:00:45 -0700 (PDT) X-Received: by 2002:a05:6214:e4a:b0:4b1:d684:f72f with SMTP id o10-20020a0562140e4a00b004b1d684f72fmr18137803qvc.3.1665482445628; Tue, 11 Oct 2022 03:00:45 -0700 (PDT) Received: from gerbillo.redhat.com (146-241-103-235.dyn.eolo.it. [146.241.103.235]) by smtp.gmail.com with ESMTPSA id u5-20020a05620a454500b006b640efe6dasm12168464qkp.132.2022.10.11.03.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Oct 2022 03:00:45 -0700 (PDT) Message-ID: <0ded6ccc2cd76b030fbe374b8cdd9aa2e54a9d04.camel@redhat.com> Subject: Re: [PATCH v5 net 2/5] udp: Call inet6_destroy_sock() in setsockopt(IPV6_ADDRFORM). From: Paolo Abeni To: Kuniyuki Iwashima , "David S. Miller" , Eric Dumazet , Jakub Kicinski , David Ahern , Hideaki YOSHIFUJI Cc: Kuniyuki Iwashima , netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org, Brian Haley Date: Tue, 11 Oct 2022 12:00:41 +0200 In-Reply-To: <20221006185349.74777-3-kuniyu@amazon.com> References: <20221006185349.74777-1-kuniyu@amazon.com> <20221006185349.74777-3-kuniyu@amazon.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE 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 Thu, 2022-10-06 at 11:53 -0700, Kuniyuki Iwashima wrote: > Commit 4b340ae20d0e ("IPv6: Complete IPV6_DONTFRAG support") forgot > to add a change to free inet6_sk(sk)->rxpmtu while converting an IPv6 > socket into IPv4 with IPV6_ADDRFORM. After conversion, sk_prot is > changed to udp_prot and ->destroy() never cleans it up, resulting in > a memory leak. > > This is due to the discrepancy between inet6_destroy_sock() and > IPV6_ADDRFORM, so let's call inet6_destroy_sock() from IPV6_ADDRFORM > to remove the difference. > > However, this is not enough for now because rxpmtu can be changed > without lock_sock() after commit 03485f2adcde ("udpv6: Add lockless > sendmsg() support"). We will fix this case in the following patch. > > Note we will rename inet6_destroy_sock() to inet6_cleanup_sock() and > remove unnecessary inet6_destroy_sock() calls in sk_prot->destroy() > in the future. > > Fixes: 4b340ae20d0e ("IPv6: Complete IPV6_DONTFRAG support") > Signed-off-by: Kuniyuki Iwashima > --- > Cc: Brian Haley > --- > include/net/ipv6.h | 1 + > net/ipv6/af_inet6.c | 6 ++++++ > net/ipv6/ipv6_sockglue.c | 20 ++++++++------------ > 3 files changed, 15 insertions(+), 12 deletions(-) > > diff --git a/include/net/ipv6.h b/include/net/ipv6.h > index d664ba5812d8..335a49ecd8a0 100644 > --- a/include/net/ipv6.h > +++ b/include/net/ipv6.h > @@ -1182,6 +1182,7 @@ void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err, __be16 port, > void ipv6_local_error(struct sock *sk, int err, struct flowi6 *fl6, u32 info); > void ipv6_local_rxpmtu(struct sock *sk, struct flowi6 *fl6, u32 mtu); > > +void inet6_cleanup_sock(struct sock *sk); > int inet6_release(struct socket *sock); > int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len); > int inet6_getname(struct socket *sock, struct sockaddr *uaddr, > diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c > index d40b7d60e00e..ded827944fa6 100644 > --- a/net/ipv6/af_inet6.c > +++ b/net/ipv6/af_inet6.c > @@ -510,6 +510,12 @@ void inet6_destroy_sock(struct sock *sk) > } > EXPORT_SYMBOL_GPL(inet6_destroy_sock); > > +void inet6_cleanup_sock(struct sock *sk) > +{ > + inet6_destroy_sock(sk); > +} > +EXPORT_SYMBOL_GPL(inet6_cleanup_sock); > + > /* > * This does both peername and sockname. > */ > diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c > index 408345fc4c5c..a20edae868fd 100644 > --- a/net/ipv6/ipv6_sockglue.c > +++ b/net/ipv6/ipv6_sockglue.c > @@ -431,9 +431,6 @@ int do_ipv6_setsockopt(struct sock *sk, int level, int optname, > if (optlen < sizeof(int)) > goto e_inval; > if (val == PF_INET) { > - struct ipv6_txoptions *opt; > - struct sk_buff *pktopt; > - > if (sk->sk_type == SOCK_RAW) > break; > > @@ -464,7 +461,6 @@ int do_ipv6_setsockopt(struct sock *sk, int level, int optname, > break; > } > > - fl6_free_socklist(sk); > __ipv6_sock_mc_close(sk); > __ipv6_sock_ac_close(sk); > > @@ -501,14 +497,14 @@ int do_ipv6_setsockopt(struct sock *sk, int level, int optname, > sk->sk_socket->ops = &inet_dgram_ops; > sk->sk_family = PF_INET; > } > - opt = xchg((__force struct ipv6_txoptions **)&np->opt, > - NULL); > - if (opt) { > - atomic_sub(opt->tot_len, &sk->sk_omem_alloc); > - txopt_put(opt); > - } > - pktopt = xchg(&np->pktoptions, NULL); > - kfree_skb(pktopt); > + > + /* Disable all options not to allocate memory anymore, > + * but there is still a race. See the lockless path > + * in udpv6_sendmsg() and ipv6_local_rxpmtu(). > + */ > + np->rxopt.all = 0; > + > + inet6_cleanup_sock(sk); I think there still a pending point raised from Eric here. """ Once the v6 socket has been transformed to IPv4 one, inet6_sock_destruct() is not going to be called. """ AFAICS the series is safe Kuniyuki noted: """ inet6_sock_destruct() is set to sk->sk_destruct(), which is not changed by the transformation and will be called from __sk_destruct(). """ [with the next patch] @Eric are you fine with the above? Thanks! Paolo > > /* > * ... and add it to the refcnt debug socks count