All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Paul Moore <paul@paul-moore.com>
Cc: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Neal Cardwell <ncardwell@google.com>,
	Kuniyuki Iwashima <kuniyu@amazon.com>,
	David Ahern <dsahern@kernel.org>,
	linux-security-module@vger.kernel.org, Xiumei Mu <xmu@redhat.com>
Subject: Re: [PATCH net v2] tcp: drop secpath at the same time as we currently drop dst
Date: Tue, 18 Feb 2025 00:14:28 +0100	[thread overview]
Message-ID: <Z7PC1JoBvgFL9JAU@hog> (raw)
In-Reply-To: <CAHC9VhT2YnbCKcAz5ff+CCnBkSwWijC4r7-meLE7wPW6iK2FUQ@mail.gmail.com>

2025-02-17, 17:35:32 -0500, Paul Moore wrote:
> On Mon, Feb 17, 2025 at 5:23 AM Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
> > Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while
> > running tests that boil down to:
> >  - create a pair of netns
> >  - run a basic TCP test over ipcomp6
> >  - delete the pair of netns
> >
> > The xfrm_state found on spi_byaddr was not deleted at the time we
> > delete the netns, because we still have a reference on it. This
> > lingering reference comes from a secpath (which holds a ref on the
> > xfrm_state), which is still attached to an skb. This skb is not
> > leaked, it ends up on sk_receive_queue and then gets defer-free'd by
> > skb_attempt_defer_free.
> >
> > The problem happens when we defer freeing an skb (push it on one CPU's
> > defer_list), and don't flush that list before the netns is deleted. In
> > that case, we still have a reference on the xfrm_state that we don't
> > expect at this point.
> >
> > We already drop the skb's dst in the TCP receive path when it's no
> > longer needed, so let's also drop the secpath. At this point,
> > tcp_filter has already called into the LSM hooks that may require the
> > secpath, so it should not be needed anymore.
> 
> I don't recall seeing any follow up in the v1 patchset regarding
> IP_CMSG_PASSSEC/security_socket_getpeersec_dgram(), can you confirm
> that the secpath is preserved for that code path?
> 
> https://lore.kernel.org/linux-security-module/CAHC9VhQZ+k1J0UidJ-bgdBGBuVX9M18tQ+a+fuqXQM_L-PFvzA@mail.gmail.com

Sorry, I thought we'd addressed this in the v1 discussion with Eric.

IP_CMSG_PASSSEC is not blocked for TCP sockets, but it will only
process skbs that came from the error queue (ip_recv_error ->
ip_cmsg_recv -> ip_cmsg_recv_offset -> ip_cmsg_recv_security ->
security_socket_getpeersec_dgram), which don't go through those code
paths at all. So AFAICT IP_CMSG_PASSSEC for TCP isn't affected by
dropping the secpath early.

-- 
Sabrina

  reply	other threads:[~2025-02-17 23:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 10:23 [PATCH net v2] tcp: drop secpath at the same time as we currently drop dst Sabrina Dubroca
2025-02-17 11:58 ` Eric Dumazet
2025-02-17 22:35 ` Paul Moore
2025-02-17 23:14   ` Sabrina Dubroca [this message]
2025-02-17 23:56     ` Paul Moore
2025-02-20  8:40 ` 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=Z7PC1JoBvgFL9JAU@hog \
    --to=sd@queasysnail.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=xmu@redhat.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.