netdev - Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f9b88268-03dc-4356-8b31-0bab73cc9b1e@I-love.SAKURA.ne.jp>
Date: Tue, 3 Feb 2026 12:47:54 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Paul Moore <paul@...l-moore.com>, SELinux <selinux@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()

On 2026/02/02 13:07, Paul Moore wrote:
> I'm asking you to verify that we have the LSM xfrm hooks in all of the
> necessary locations to ensure that we are safely and comprehensively
> gating all of the operations that result in removal of SPD and SAD
> entries.

That is impossible. We can't have the LSM xfrm hooks in all locations
that result in removal of SPD and SAD entries. We must give up trying
to have the LSM xfrm hooks in NETDEV_UNREGISTER event handler despite
NETDEV_UNREGISTER event handler results in removal of SPD and SAD entries.

>> No authorization can be placed during must-not-fail operation.
> 
> Of course, but that means that we simply need to make sure we have the
> authorization hooks placed elsewhere to ensure that users can not
> remove SPD and SAD entries if they are not allowed.  I'm not arguing
> about if returning an error in a place that can not handle an error
> condition is correct or not, I'm arguing that you should audit the SPD
> and SAD removal code paths to ensure that they all have the proper LSM
> xfrm hook authorizations.

This patch just removes error-returning LSM xfrm hook calls from one of
must-not-fail locations. I attach two syzbot reports that demonstrate
a result of having LSM xfrm hook calls from NETDEV_UNREGISTER event
( https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/net/xfrm?h=next-20260202&id=638361ad7ab20c5740d9637d3a51306f9b2e1461 ) .

As you can see, this must-not-fail operation is triggered by both
"sendmsg() system call (i.e. sending netlink message) by a userspace process"
and "the cleanup_net kernel WQ thread".

You might be able to call LSM xfrm hooks before netlink_sendmsg() is authorized
(assuming that that LSM hook can examine what SPD and SAD entries will be deleted
by allow processing netlink_sendmsg() request), but I guess that it will be
subjected to TOCTOU problem; can we have such giant lock that can serialize all
operations that might be triggered by allow calling netlink_sendmsg()? Even if
you had such giant lock, what about cleanup_net() path that happens without
explicit request from userspace?

It is your role (not my role) to verify that we have the LSM xfrm hooks in all
of the necessary locations, for it is you who is wishing to ensure that we are
safely and comprehensively gating all of the operations that result in removal
of SPD and SAD entries. The reports I attached are suggesting you that we can't
safely and comprehensively gate all of the operations that result in removal of
SPD and SAD entries.

Reported-by: syzbot+881d65229ca4f9ae8c84@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84

View attachment "report-20260202-cleanup_net.txt" of type "text/plain" (73840 bytes)

View attachment "report-20260202-netlink_sendmsg.txt" of type "text/plain" (76858 bytes)