From: Paolo Abeni <pabeni@redhat.com>
To: Norbert Szetei <norbert@doyensec.com>, netdev@vger.kernel.org
Cc: Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Daniel Zahka <daniel.zahka@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: psp: do not inherit the Rx association on clone
Date: Tue, 1 Sep 2026 12:01:09 +0200 [thread overview]
Message-ID: <924455c8-9f62-491f-ae3c-ea2127f46769@redhat.com> (raw)
In-Reply-To: <BC10EB92-ABB3-41B2-AB16-266BEEBE18C0@doyensec.com>
On 8/29/26 6:56 PM, Norbert Szetei wrote:
> sk->psp_assoc sits past sk_dontcopy_end, so sock_copy() copies it into
> every socket accepted from a listener without taking a reference, while
> inet_sock_destruct() puts for every inet socket. psp_twsk_init() does
> refcount_inc() for the timewait socket, so a child closing through
> TIME_WAIT cancels its own put and leaves the association with one
> reference and N timewait sockets holding the same pointer. Closing the
> listener frees it, and the timewait timers then put freed memory.
>
> Rejecting the association on a listening socket is not sufficient: a socket
> can acquire one while established and then be turned back into a listener,
> because tcp_disconnect() leaves sk->psp_assoc in place.
So rejecting the association on listener, and clearing on disconnect
would be enough, right?
I think that would be preferable: it's a pity to add safeguard code to
the datapath due to a syscall (disconnect) used mostly by fuzzers.
/P
next prev parent reply other threads:[~2026-09-01 10:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 16:56 [PATCH net] net: psp: do not inherit the Rx association on clone Norbert Szetei
2026-08-29 20:40 ` Daniel Zahka
2026-08-30 18:07 ` Norbert Szetei
2026-09-01 10:01 ` Paolo Abeni [this message]
2026-09-01 12:28 ` Daniel Zahka
2026-09-01 13:10 ` Paolo Abeni
2026-09-01 13:20 ` 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=924455c8-9f62-491f-ae3c-ea2127f46769@redhat.com \
--to=pabeni@redhat.com \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=norbert@doyensec.com \
--cc=willemb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.