mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <edumazet@google.com>
Cc: <davem@davemloft.net>, <dsahern@kernel.org>, <kuba@kernel.org>,
	<kuni1840@gmail.com>, <kuniyu@amazon.com>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<pabeni@redhat.com>, <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH v2 net 2/5] udp: Call inet6_destroy_sock() in setsockopt(IPV6_ADDRFORM).
Date: Tue, 27 Sep 2022 22:29:05 -0700	[thread overview]
Message-ID: <20220928052905.82271-1-kuniyu@amazon.com> (raw)
In-Reply-To: <CANn89iK1HHhvJgDsym377DDxZ3hvL8b8_pbrjb-qeXFRbsvFKA@mail.gmail.com>

From:   Eric Dumazet <edumazet@google.com>
Date:   Tue, 27 Sep 2022 22:05:09 -0700
> On Tue, Sep 27, 2022 at 5:28 PM Kuniyuki Iwashima <kuniyu@amazon.com> 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.
> >
> > Fixes: 4b340ae20d0e ("IPv6: Complete IPV6_DONTFRAG support")
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> > ---
> >  net/ipv6/ipv6_sockglue.c | 15 +++------------
> >  1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> > index b61066ac8648..030a4cf23ceb 100644
> > --- a/net/ipv6/ipv6_sockglue.c
> > +++ b/net/ipv6/ipv6_sockglue.c
> > @@ -431,9 +431,6 @@ static 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 @@ static 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,9 @@ static 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);
> > +
> 
>  Why is this needed ? I think a comment could help.
> > +                       np->rxopt.all = 0;

I added it to reduce the possibility of lockless allocation in
ipv6_local_rxpmtu(), which checks np->rxopt.bits.rxpmtu first.

But, lockless sendmsg() even races with this, so it might not be
needed or should be added in the next patch?


> 
> > +                       inet6_destroy_sock(sk);
> 
> This name is unfortunate. This really is an inet6_cleanup_sock() in
> this context.

Ok, I'll add inet6_cleanup_sock() as a wrapper of inet6_destroy_sock()
in v3.

And, I'll post a cleanup patch later which renames inet6_destroy_sock()
to inet6_cleanup_sock() and removes all unnecessary inet6_destroy_sock()
calls in each sk->sk_prot->destroy().


> 
> >
> >                         /*
> >                          * ... and add it to the refcnt debug socks count
> > --
> > 2.30.2

  reply	other threads:[~2022-09-28  5:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28  0:27 [PATCH v2 net 0/5] tcp/udp: Fix memory leaks and data races around IPV6_ADDRFORM Kuniyuki Iwashima
2022-09-28  0:27 ` [PATCH v2 net 1/5] tcp/udp: Fix memory leak in ipv6_renew_options() Kuniyuki Iwashima
2022-09-28  0:27 ` [PATCH v2 net 2/5] udp: Call inet6_destroy_sock() in setsockopt(IPV6_ADDRFORM) Kuniyuki Iwashima
2022-09-28  5:05   ` Eric Dumazet
2022-09-28  5:29     ` Kuniyuki Iwashima [this message]
2022-09-28  0:27 ` [PATCH v2 net 3/5] tcp/udp: Call inet6_destroy_sock() in IPv6 sk->sk_destruct() Kuniyuki Iwashima
2022-09-28  3:43   ` Eric Dumazet
2022-09-28  4:00     ` Kuniyuki Iwashima
2022-09-28  4:10       ` Eric Dumazet
2022-09-28  4:31         ` Kuniyuki Iwashima
2022-09-28  0:27 ` [PATCH v2 net 4/5] ipv6: Fix data races around sk->sk_prot Kuniyuki Iwashima
2022-09-28  0:27 ` [PATCH v2 net 5/5] tcp: Fix data races around icsk->icsk_af_ops Kuniyuki Iwashima

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220928052905.82271-1-kuniyu@amazon.com \
    --to=kuniyu@amazon.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kuni1840@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®