From: Steffen Klassert <steffen.klassert@secunet.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Aviad Yehezkel <aviadye@mellnaox.com>,
Aviv Heller <avivh@mellanox.com>,
Boris Pismenny <borisp@mellanox.com>,
"David S. Miller" <davem@davemloft.net>,
Florian Westphal <fw@strlen.de>, Guy Shapiro <guysh@mellanox.com>,
Ilan Tayari <ilant@mellanox.com>,
Kristian Evensen <kristian.evensen@gmail.com>,
Leon Romanovsky <leon@kernel.org>,
Leon Romanovsky <leonro@nvidia.com>,
Raed Salem <raeds@mellanox.com>, Raed Salem <raeds@nvidia.com>,
Saeed Mahameed <saeedm@mellanox.com>,
Yossi Kuperman <yossiku@mellanox.com>,
Network Development <netdev@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event
Date: Thu, 22 Jan 2026 12:15:18 +0100 [thread overview]
Message-ID: <aXIGxmCB2QU86-iA@secunet.com> (raw)
In-Reply-To: <287edf7f-85fb-46c3-9c70-c8ec7014a0db@I-love.SAKURA.ne.jp>
On Thu, Jan 22, 2026 at 05:24:22PM +0900, Tetsuo Handa wrote:
> A debug patch in linux-next-20260121
> ( https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=fc0f090e41e652d158f946c616cdd82baed3c8f4 )
> has demonstrated that calling xfrm_dev_state_flush()/xfrm_dev_policy_flush()
> when (dev->features & NETIF_F_HW_ESP) == 0 helps releasing "struct net_device" refcount.
>
> unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2
> ref_tracker: netdev@ffff88805d3c0628 has 1/1 users at
> xfrm_dev_state_add+0x6f4/0xc40 net/xfrm/xfrm_device.c:316
> xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline]
> xfrm_add_sa+0x34ca/0x4230 net/xfrm/xfrm_user.c:1022
> xfrm_user_rcv_msg+0x746/0xb20 net/xfrm/xfrm_user.c:3507
> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
> xfrm_netlink_rcv+0x79/0x90 net/xfrm/xfrm_user.c:3529
> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344
> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
> sock_sendmsg_nosec+0x18f/0x1d0 net/socket.c:737
> __sock_sendmsg net/socket.c:752 [inline]
> ____sys_sendmsg+0x589/0x8c0 net/socket.c:2610
> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2664
> __sys_sendmsg net/socket.c:2696 [inline]
> __do_sys_sendmsg net/socket.c:2701 [inline]
> __se_sys_sendmsg net/socket.c:2699 [inline]
> __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2699
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> infiniband: balance for netdevsim0@ib_gid_table_entry is 0
> ***** Releasing 1 refcount on 0000000000000000
> ***** Refcount for netdevsim0 changed from 2 to 1
>
> The bond_master_netdev_event(NETDEV_UNREGISTER) case is already calling
> xfrm_dev_state_flush() without checking (dev->features & NETIF_F_HW_ESP) != 0.
> Therefore, I assume that (dev->features & NETIF_F_HW_ESP) != 0 check in
> xfrm_dev_down() is wrong, and I would like to propose
>
> static int xfrm_dev_down(struct net_device *dev)
> {
> - if (dev->features & NETIF_F_HW_ESP) {
> - xfrm_dev_state_flush(dev_net(dev), dev, true);
> - xfrm_dev_policy_flush(dev_net(dev), dev, true);
> - }
> + xfrm_dev_state_flush(dev_net(dev), dev, true);
> + xfrm_dev_policy_flush(dev_net(dev), dev, true);
>
> return NOTIFY_DONE;
> }
Hm, I'd say we should not try to offload to a device that does
not support NETIF_F_HW_ESP.
>
> change as a fix for "unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2"
> problem.
>
>
>
> But I have a question regarding security_xfrm_state_delete()/security_xfrm_policy_delete().
>
> xfrm_dev_state_flush_secctx_check() calls security_xfrm_state_delete() which can make
> xfrm_dev_state_flush() no-op by returning an error value.
> xfrm_dev_policy_flush_secctx_check() calls security_xfrm_policy_delete() which can make
> xfrm_dev_policy_flush() no-op by returning an error value.
>
> Since xfrm_dev_state_flush()/xfrm_dev_policy_flush() are called by NETDEV_UNREGISTER
> event (which is a signal for releasing all resources that prevent "struct net_device"
> references from dropping), making xfrm_dev_state_flush()/xfrm_dev_policy_flush() no-op (by
> allowing security_xfrm_state_delete()/security_xfrm_policy_delete() to return an error) is
> a denial-of-service bug.
This means that the calling task doesn't have the permission to delete the
state, some LSM has a policy the does not grant this permission.
>
> Therefore, I wonder what are security_xfrm_state_delete() and security_xfrm_policy_delete()
> for. Can I kill xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check() ?
This might violate a LSM policy then.
next prev parent reply other threads:[~2026-01-22 11:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-17 16:03 xfrm: question regarding NETDEV_UNREGISTER handling Tetsuo Handa
2026-01-19 11:19 ` [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event Tetsuo Handa
2026-01-22 8:24 ` Tetsuo Handa
2026-01-22 11:15 ` Steffen Klassert [this message]
2026-01-22 11:28 ` Tetsuo Handa
2026-01-22 11:32 ` Steffen Klassert
2026-01-22 13:07 ` Tetsuo Handa
2026-01-26 11:07 ` Leon Romanovsky
2026-01-26 15:57 ` Tetsuo Handa
2026-01-26 14:16 ` Sabrina Dubroca
2026-01-26 22:41 ` 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=aXIGxmCB2QU86-iA@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=aviadye@mellnaox.com \
--cc=avivh@mellanox.com \
--cc=borisp@mellanox.com \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=guysh@mellanox.com \
--cc=ilant@mellanox.com \
--cc=kristian.evensen@gmail.com \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=raeds@mellanox.com \
--cc=raeds@nvidia.com \
--cc=saeedm@mellanox.com \
--cc=yossiku@mellanox.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.