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;
MIME-Version: 1.0
References: <CANn89iKn4rpqj_8fYt0UMMgAq5L_2PNoY0Ev70ck8u4t4FC_=g@mail.gmail.com>
 <20230405194143.15708-1-kuniyu@amazon.com> <CANn89iJeHFb8VnFPUq4-d+jzAO6XKiSQhaPsPFY98wjH0Yx1Lw@mail.gmail.com>
In-Reply-To: <CANn89iJeHFb8VnFPUq4-d+jzAO6XKiSQhaPsPFY98wjH0Yx1Lw@mail.gmail.com>
From:   "Dae R. Jeong" <threeearcat@gmail.com>
Date:   Thu, 6 Apr 2023 07:17:30 +0900
Message-ID: <CACsK=jf=nO-2N5HhqKd80m6RYpAFEd8rfUBrog6sKgnLuUnd9w@mail.gmail.com>
Subject: Re: KASAN: use-after-free Read in tcp_write_timer_handler
To:     Eric Dumazet <edumazet@google.com>
Cc:     Kuniyuki Iwashima <kuniyu@amazon.com>, bpf@vger.kernel.org,
        davem@davemloft.net, dsahern@kernel.org, kuba@kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        pabeni@redhat.com, yoshfuji@linux-ipv6.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Apr 6, 2023 at 4:48=E2=80=AFAM Eric Dumazet <edumazet@google.com> w=
rote:
>
> On Wed, Apr 5, 2023 at 9:42=E2=80=AFPM Kuniyuki Iwashima <kuniyu@amazon.c=
om> wrote:
> >
> > From:   Eric Dumazet <edumazet@google.com>
> > Date:   Wed, 5 Apr 2023 13:28:16 +0200
> > > On Wed, Apr 5, 2023 at 12:41=E2=80=AFPM Dae R. Jeong <threeearcat@gma=
il.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > We observed an issue "KASAN: use-after-free Read in tcp_write_timer=
_handler" during fuzzing.
> > > >
> > > > Unfortunately, we have not found a reproducer for the crash yet. We
> > > > will inform you if we have any update on this crash.  Detailed cras=
h
> > > > information is attached below.
> > > >
> > >
> > > Thanks for the report.
> > >
> > > I have dozens of similar syzbot reports, with no repro.
> > >
> > > I usually hold them, because otherwise it is just noise to mailing li=
sts.
> > >
> > > Normally, all user TCP sockets hold a reference on the netns
> > >
> > > In all these cases, we see a netns being dismantled while there is at
> > > least one socket with a live timer.
> > >
> > > This is therefore a kernel TCP socket, for which we do not have yet
> > > debugging infra ( REF_TRACKER )
> > >
> > > CONFIG_NET_DEV_REFCNT_TRACKER=3Dy is helping to detect too many dev_p=
ut(),
> > > we need something tracking the "kernel sockets" as well.
> >
> > Maybe I missed something, but we track kernel sockets with netns
> > by notrefcnt_tracker ?
>
> Oh right, I forgot I did this already :)
>
> commit 0cafd77dcd032d1687efaba5598cf07bce85997f
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Thu Oct 20 23:20:18 2022 +0000
>
>     net: add a refcount tracker for kernel sockets
>
> Dae, make sure to not send reports based on old kernels.
>
> Using 6.0-rc7 is a waste of your time, and everyone else reading this thr=
ead.
>
> I confess I did not check this, and I really should do that all the time.

I'm sorry and I understand your time is valuable.
I will let you know when I observe this issue again.

>
> >
> > I thought now CONFIG_NET_NS_REFCNT_TRACKER can catch the case.
> >
> >
> > >
> > > Otherwise bugs in subsystems not properly dismantling their kernel
> > > socket at netns dismantle are next to impossible to track and fix.
> > >
> > > If anyone has time to implement this, feel free to submit patches.
> > >
> > > Thanks.

Best regards,
Dae R. Jeong.