From: Jakub Kicinski <kuba@kernel•org>
To: Eric Dumazet <edumazet@google•com>
Cc: "David S . Miller" <davem@davemloft•net>,
Paolo Abeni <pabeni@redhat•com>,
netdev@vger•kernel.org, eric.dumazet@gmail•com,
Josef Bacik <josef@toxicpanda•com>,
Tetsuo Handa <penguin-kernel@i-love•sakura.ne.jp>
Subject: Re: [PATCH net] tcp: properly terminate timers for kernel sockets
Date: Mon, 25 Mar 2024 06:34:01 -0700 [thread overview]
Message-ID: <20240325063401.7d7f3d35@kernel.org> (raw)
In-Reply-To: <CANn89iJ-TJY8Bf_6W2yh1F4V0qBNNUKk0NGNT2XJN9Or0oRgdg@mail.gmail.com>
On Sat, 23 Mar 2024 05:45:26 +0100 Eric Dumazet wrote:
> > On Fri, 22 Mar 2024 13:57:32 +0000 Eric Dumazet wrote:
> > > + if (!sk->sk_net_refcnt)
> > > + inet_csk_clear_xmit_timers_sync(sk);
> >
> > The thought that we should clear or poison sk_net at this point
> > (whether sk->sk_net_refcnt or not) keeps coming back to me.
> > If we don't guarantee the pointer is valid - to make it easier
> > for syzbot to catch invalid accesses?
>
> I do not think we should do this here.
>
> Note that KASAN has quarantine, and can catch invalid UAF accesses anyway.
>
> We could clear the base socket in sk_prot_free() but this will not
> make KASAN better.
I was thinking mostly about the kernel sockets being "special",
and therefore less well exercised by syzbot. But sk_net will
remain valid until all user space for that netns exists, IIUC,
so I take it back, the clearing has a real chance of adding bugs.
next prev parent reply other threads:[~2024-03-25 13:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 13:57 [PATCH net] tcp: properly terminate timers for kernel sockets Eric Dumazet
2024-03-22 14:58 ` Josef Bacik
2024-03-22 22:47 ` Jakub Kicinski
2024-03-23 4:45 ` Eric Dumazet
2024-03-25 13:34 ` Jakub Kicinski [this message]
2024-03-26 3:10 ` patchwork-bot+netdevbpf
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=20240325063401.7d7f3d35@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=josef@toxicpanda$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=penguin-kernel@i-love$(echo .)sakura.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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