netdev - xfrm: question regarding NETDEV

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>] [day] [month] [year] [list]

Message-ID: <924f9cf5-599a-48f0-b1e3-94cd971965b0@I-love.SAKURA.ne.jp>
Date: Sun, 18 Jan 2026 01:03:27 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Aviad Yehezkel <aviadye@...lnaox.com>, Aviv Heller <avivh@...lanox.com>,
        Boris Pismenny <borisp@...lanox.com>,
        "David S. Miller"
 <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>, Guy Shapiro <guysh@...lanox.com>,
        Ilan Tayari <ilant@...lanox.com>,
        Kristian Evensen <kristian.evensen@...il.com>,
        Leon Romanovsky <leon@...nel.org>, Leon Romanovsky <leonro@...dia.com>,
        Raed Salem <raeds@...lanox.com>, Raed Salem <raeds@...dia.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Yossi Kuperman <yossiku@...lanox.com>
Cc: Network Development <netdev@...r.kernel.org>
Subject: xfrm: question regarding NETDEV_UNREGISTER handling

syzbot is reporting that "struct xfrm_state" refcount is leaking.

  unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2
  ref_tracker: netdev@...f888052f24618 has 1/1 users at
       __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]
       netdev_tracker_alloc include/linux/netdevice.h:4412 [inline]
       xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316
       xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline]
       xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022
       xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507
       netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550
       xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529
       netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
       netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344
       netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894
       sock_sendmsg_nosec net/socket.c:727 [inline]
       __sock_sendmsg net/socket.c:742 [inline]
       ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592
       ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646
       __sys_sendmsg+0x16d/0x220 net/socket.c:2678
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

Commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") introduced
xfrm_dev_state_add() which grabs a reference to "struct net_device".
That commit called xfrm_dev_state_add() from xfrm_state_construct() and
introduced the NETDEV_UNREGISTER case to xfrm_dev_event(), but
xfrm_dev_unregister() was a no-op (rather than doing necessary actions
for releasing "struct xfrm_state" which will in turn drop the reference
to "struct net_device").

Commit 152afb9b45a8 ("xfrm: Indicate xfrm_state offload errors") added
proper error code propagation, and commit cc01572e2fb0 ("xfrm: Add SA to
hardware at the end of xfrm_state_construct()") moved the location to call
xfrm_dev_state_add(), but these commits did not touch NETDEV_UNREGISTER
handling.

Commit ec30d78c14a8 ("xfrm: add xdst pcpu cache") added
xfrm_policy_cache_flush() call to xfrm_dev_unregister(), but
commit e4db5b61c572 ("xfrm: policy: remove pcpu policy cache") removed
xfrm_policy_cache_flush() call from xfrm_dev_unregister() and also
removed the NETDEV_UNREGISTER case from xfrm_dev_event() because
xfrm_dev_unregister() became no-op.

Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device")
re-introduced the NETDEV_UNREGISTER case to xfrm_dev_event(), but that
commit chose to do the same thing for NETDEV_DOWN case and
NETDEV_UNREGISTER case. Since xfrm_dev_down() is no-op unless
(dev->features & NETIF_F_HW_ESP) != 0, no necessary actions are done for
releasing "struct xfrm_state" (for at least !NETIF_F_HW_ESP case).

Commit 919e43fad516 ("xfrm: add an interface to offload policy") added
xfrm_dev_policy_flush() to xfrm_dev_down(). I don't know whether this commit
is relevant or not.

But I feel that calling xfrm_dev_state_add() and  xfrm_dev_policy_add()
are possible for !NETIF_F_HW_ESP case. If my feeling is correct, we have
never implemented proper NETDEV_UNREGISTER handling for releasing
"struct xfrm_state". What actions are needed for properly releasing
"struct xfrm_state" from NETDEV_UNREGISTER handler?