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;
From:   Kuniyuki Iwashima <kuniyu@amazon.com>
To:     <edumazet@google.com>
CC:     <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>,
        <threeearcat@gmail.com>, <yoshfuji@linux-ipv6.org>,
        <kuniyu@amazon.com>
Subject: Re: KASAN: use-after-free Read in tcp_write_timer_handler
Date:   Wed, 5 Apr 2023 12:41:43 -0700
Message-ID: <20230405194143.15708-1-kuniyu@amazon.com>
In-Reply-To: <CANn89iKn4rpqj_8fYt0UMMgAq5L_2PNoY0Ev70ck8u4t4FC_=g@mail.gmail.com>
References: <CANn89iKn4rpqj_8fYt0UMMgAq5L_2PNoY0Ev70ck8u4t4FC_=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

From:   Eric Dumazet <edumazet@google.com>
Date:   Wed, 5 Apr 2023 13:28:16 +0200
> On Wed, Apr 5, 2023 at 12:41 PM Dae R. Jeong <threeearcat@gmail.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 crash
> > 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 lists.
> 
> 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=y is helping to detect too many dev_put(),
> we need something tracking the "kernel sockets" as well.

Maybe I missed something, but we track kernel sockets with netns
by notrefcnt_tracker ?

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.