netdev.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).