linux-kernel - Re: KASAN: use-after-free Read in tcp_write_timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Apr 2023 12:41:43 -0700
From:   Kuniyuki Iwashima <kuniyu@...zon.com>
To:     <edumazet@...gle.com>
CC:     <bpf@...r.kernel.org>, <davem@...emloft.net>, <dsahern@...nel.org>,
        <kuba@...nel.org>, <linux-kernel@...r.kernel.org>,
        <netdev@...r.kernel.org>, <pabeni@...hat.com>,
        <threeearcat@...il.com>, <yoshfuji@...ux-ipv6.org>,
        <kuniyu@...zon.com>
Subject: Re: KASAN: use-after-free Read in tcp_write_timer_handler

From:   Eric Dumazet <edumazet@...gle.com>
Date:   Wed, 5 Apr 2023 13:28:16 +0200
> On Wed, Apr 5, 2023 at 12:41 PM Dae R. Jeong <threeearcat@...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 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.