From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B36E2C433F5 for ; Tue, 3 May 2022 13:45:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236468AbiECNtX (ORCPT ); Tue, 3 May 2022 09:49:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236456AbiECNtT (ORCPT ); Tue, 3 May 2022 09:49:19 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E21B760EA for ; Tue, 3 May 2022 06:45:45 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id e12so31086928ybc.11 for ; Tue, 03 May 2022 06:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g1pU5XI6ljn+7UJoKbM3rS+gYEntC9K9xEfeaVv0hHY=; b=itRY4PSZQZEtMhK3UggR+gtKNEgiWeV4zElcf2qYwF2LAHJzpFo2KaaVt1aACJM92e VQ5gYJ8bF6MW6mMUIwHJ+pLGjkhT+veWpvGLovwfVLtG0BSoZ3zGxuAOAz4rGB4B8g+X XGumnrMXN6ireNNroaHZzYrS4My+eVCz4xpIgszWasdrQgmmSZ0q95X1aJy2WPB183HC 2thVkHvsk8LWDKCPq0k62XofdYoNxPgaI8vrD5EcphVKnRVQt40yXWR/cFxnHj9LFgOI aVASJG+OUCpHN6m+LnL8IoJ3Yoq6C+Joh/onVo2GsI/EZrKEO/qvHzNIGvxcbRnhvFWK 7hpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g1pU5XI6ljn+7UJoKbM3rS+gYEntC9K9xEfeaVv0hHY=; b=fmxKivDvZO3O0DcbbEzFJlUTNG3yQ4b+YXA56FmwnjXsF7l8dqmbAgtLte7/12ThLm IgiCrZaotabnFTd0KAs1dhX5o2Ca5HNcR6GqaTXKs958t3EHeREoXPJv2kpdnG4txxKd kP3idVP712wp/tBdqwCxuQ2T6pQmJhl5wliVVgw4fm2YLSJAJ+UJY5F+s3Rp0zFqSTiX AwQncdY0ZZVeonK0/tpslx8W0mKAllEWQ9K0wntpcHS5kT7JoTFgkYr3Z8rfOBHYFyk/ ne9OVLuV3MqImzuTZ9tBJLi3tq+WAigmVjxlPZ6vIycAcWiT6sEYOEoOAAp0Ofx+2RMR IaXA== X-Gm-Message-State: AOAM530aJ+GwcLJbPGgoN31xV3UjLskcyC+l7CayuexaSkOJ8fySJigO DzGkuODfeONVXWALrzRqryMpMfYbpilfQ562JOgo2A== X-Google-Smtp-Source: ABdhPJx3eWh0jJqJT+d0YzradfinfQxNdPwhkhHj7yULlZrdGRESZEz5iu3aXozlUUIF3GRE66s+EBtNoRMmHwA1Uck= X-Received: by 2002:a25:6157:0:b0:645:8d0e:f782 with SMTP id v84-20020a256157000000b006458d0ef782mr14803876ybb.36.1651585544858; Tue, 03 May 2022 06:45:44 -0700 (PDT) MIME-Version: 1.0 References: <00000000000045dc96059f4d7b02@google.com> <000000000000f75af905d3ba0716@google.com> <5f90c2b8-283e-6ca5-65f9-3ea96df00984@I-love.SAKURA.ne.jp> <3b6bc24c8cd3f896dcd480ff75715a2bf9b2db06.camel@redhat.com> In-Reply-To: <3b6bc24c8cd3f896dcd480ff75715a2bf9b2db06.camel@redhat.com> From: Eric Dumazet Date: Tue, 3 May 2022 06:45:33 -0700 Message-ID: Subject: Re: [PATCH v2] net: rds: acquire refcount on TCP sockets To: Paolo Abeni Cc: Tetsuo Handa , Santosh Shilimkar , "David S. Miller" , Jakub Kicinski , syzbot , netdev , syzkaller-bugs , OFED mailing list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, May 3, 2022 at 2:02 AM Paolo Abeni wrote: > > Hello, > > On Mon, 2022-05-02 at 10:40 +0900, Tetsuo Handa wrote: > > syzbot is reporting use-after-free read in tcp_retransmit_timer() [1], > > for TCP socket used by RDS is accessing sock_net() without acquiring a > > refcount on net namespace. Since TCP's retransmission can happen after > > a process which created net namespace terminated, we need to explicitly > > acquire a refcount. > > > > Link: https://syzkaller.appspot.com/bug?extid=694120e1002c117747ed [1] > > Reported-by: syzbot > > Fixes: 26abe14379f8e2fa ("net: Modify sk_alloc to not reference count the netns of kernel sockets.") > > Fixes: 8a68173691f03661 ("net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket") > > Signed-off-by: Tetsuo Handa > > Tested-by: syzbot > > --- > > Changes in v2: > > Add Fixes: tag. > > Move to inside lock_sock() section. > > > > I chose 26abe14379f8e2fa and 8a68173691f03661 which went to 4.2 for Fixes: tag, > > for refcount was implicitly taken when 70041088e3b97662 ("RDS: Add TCP transport > > to RDS") was added to 2.6.32. > > > > net/rds/tcp.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/net/rds/tcp.c b/net/rds/tcp.c > > index 5327d130c4b5..2f638f8b7b1e 100644 > > --- a/net/rds/tcp.c > > +++ b/net/rds/tcp.c > > @@ -495,6 +495,14 @@ void rds_tcp_tune(struct socket *sock) > > > > tcp_sock_set_nodelay(sock->sk); > > lock_sock(sk); > > + /* TCP timer functions might access net namespace even after > > + * a process which created this net namespace terminated. > > + */ > > + if (!sk->sk_net_refcnt) { > > + sk->sk_net_refcnt = 1; > > + get_net_track(net, &sk->ns_tracker, GFP_KERNEL); > > + sock_inuse_add(net, 1); > > + } > > if (rtn->sndbuf_size > 0) { > > sk->sk_sndbuf = rtn->sndbuf_size; > > sk->sk_userlocks |= SOCK_SNDBUF_LOCK; > > This looks equivalent to the fix presented here: > > https://lore.kernel.org/all/CANn89i+484ffqb93aQm1N-tjxxvb3WDKX0EbD7318RwRgsatjw@mail.gmail.com/ I think this is still needed for layers (NFS ?) that dismantle their TCP sockets whenever a netns is dismantled. But RDS case was different, only the listener is a kernel socket. > > but the latter looks a more generic solution. @Tetsuo could you please > test the above in your setup? > > Thanks! > > Paolo >