From: Steffen Klassert <steffen.klassert@secunet.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Paul Moore <paul@paul-moore.com>,
SELinux <selinux@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
Date: Wed, 18 Feb 2026 10:22:36 +0100 [thread overview]
Message-ID: <aZWE3F8ppQgN3Gwe@secunet.com> (raw)
In-Reply-To: <d20f1b63-714f-48ba-9bee-cd074205404f@I-love.SAKURA.ne.jp>
On Fri, Feb 13, 2026 at 10:59:15PM +0900, Tetsuo Handa wrote:
> On 2026/02/13 19:19, Steffen Klassert wrote:
> On 2026/02/13 19:19, Steffen Klassert wrote:
> >> The NETDEV_UNREGISTER path can be triggered by just doing "unshare -n ip addr show"
> >> (i.e. implicit cleanup of a network namespace due to termination of init process in
> >> that namespace). We are not allowed to reject the cleanup_net() route.
> >
> > And here we come to the other problem I mentioned. When a LSM policy
> > rejects to flush the xfrm states and policies on network namespace
> > exit, we leak all the xfrm states and policies in that namespace.
> > Here we have no other option, we must flush the xfrm states and
> > policies regardless of any LSM policy. This can be fixed with
> > something like that:
>
> This something is what I explained at
> https://lkml.kernel.org/r/1bb453af-3ef2-4ab6-a909-0705bd07c136@I-love.SAKURA.ne.jp .
> The "task_valid" argument does not always reflect whether LSM policy can reject or not.
That was to fix the memleak on network namespace exit.
The task_valid check should be ok for xfrm_policy_flush()
and xfrm_state_flush().
>
> Anyway, the patch to add xfrm_dev_unregister(dev) seems OK if we do like
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?h=next-20260123&id=fc0f090e41e652d158f946c616cdd82baed3c8f4 ?
That would be OK as a first fix. Later we should
just unlink policies and states from the device,
as explained in my last mail.
next prev parent reply other threads:[~2026-02-18 9:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 10:08 [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check() Tetsuo Handa
2026-01-26 22:33 ` Paul Moore
2026-01-27 3:51 ` Tetsuo Handa
2026-01-27 21:59 ` Paul Moore
2026-01-28 10:28 ` Tetsuo Handa
2026-01-30 21:56 ` Paul Moore
2026-01-31 6:00 ` Tetsuo Handa
2026-02-02 4:07 ` Paul Moore
2026-02-03 3:47 ` Tetsuo Handa
2026-02-03 22:40 ` Paul Moore
2026-02-04 10:15 ` Tetsuo Handa
2026-02-04 13:57 ` Tetsuo Handa
2026-02-09 9:25 ` Steffen Klassert
2026-02-09 10:02 ` Tetsuo Handa
2026-02-09 11:22 ` Steffen Klassert
2026-02-09 14:26 ` Tetsuo Handa
2026-02-13 10:19 ` Steffen Klassert
2026-02-13 13:59 ` Tetsuo Handa
2026-02-18 9:22 ` Steffen Klassert [this message]
2026-02-27 1:14 ` Paul Moore
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=aZWE3F8ppQgN3Gwe@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=selinux@vger.kernel.org \
/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