From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 996802BB13 for ; Tue, 17 Feb 2026 13:46:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771335962; cv=none; b=Zx4/KlMX/yhCOQaWn9q6AwMY/sHq9z8CybNy1cOniYuEffDFp/x02FXu7JhGyG8jtT9Qj2HHJt7yhJ1jm4TrySMi1QWmS+ZAuzRGP2GftjCCQY4xqvA78AUVTTcPN5OCMWfqWzdo+MTLXAfy+4rRvJaDP9x9nl1owEYO73axCSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771335962; c=relaxed/simple; bh=0ZBl5qpdUhrU2mBAkX2uM37Wzm1vxIJTIn43bIevzq0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OXT10uRR46aAADszHVFds6yjJkcOnBieWmHxH86YUQJ0BY3d1GrvReS2KG5QovYXx+CkU62gU+RPIIEIQRHGyCWZ5eeYtn58P3rr6fI+739jn6y9QVdYOYK3ULfHxJxLbbjw2zqhEob70gvsANhZqtHjDcDVUncMYv//o5pfx58= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=omyEwlTe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="omyEwlTe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1D3EC4CEF7; Tue, 17 Feb 2026 13:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771335962; bh=0ZBl5qpdUhrU2mBAkX2uM37Wzm1vxIJTIn43bIevzq0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=omyEwlTeu3jS/NAhlllSCs9S1BXKVgpYiEkbZrqj+yxQk9ypPXzEUl40E2PcG6ooJ C1fHusj6yyLiQYGUOOh1JlKSOEHtiD6+3DpX0uOIoAqrG0xmaP+t40V/RfDPwv7FXo sleq/rTWGynCc5LeYwdGD5x0iaiifOuKn2HnZJtSAUjZa6mKhWDIo/dQ61+R/iKg/9 D4ofPSDp7DYo5ysIFTcdqXB7CMGCFzb2p4wVa4zk6wTHm/Co5uVEUuhdZ4sbornmk2 lF/lpd+QE4OI/oEbBbORR0/6fCzXlwCqeM3TVQW72Pxt3JHqBjZEQ/RQeIfJlRfOJ7 TViVtCTzV0V7w== Date: Tue, 17 Feb 2026 15:45:58 +0200 From: Leon Romanovsky To: Steffen Klassert Cc: Tetsuo Handa , Sabrina Dubroca , Herbert Xu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Ilan Tayari , Guy Shapiro , Yossi Kuperman , Network Development Subject: Re: [PATCH net v2] xfrm: always flush state and policy upon NETDEV_UNREGISTER event Message-ID: <20260217134558.GO12989@unreal> References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Feb 17, 2026 at 10:52:43AM +0100, Steffen Klassert wrote: > On Fri, Jan 30, 2026 at 07:42:47PM +0900, Tetsuo Handa wrote: > > syzbot is reporting that "struct xfrm_state" refcount is leaking. > > > > unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 > > ref_tracker: netdev@ffff888052f24618 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 > > > > This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware > > offloading API") implemented xfrm_dev_unregister() as no-op despite > > xfrm_dev_state_add() from xfrm_state_construct() acquires a reference > > to "struct net_device". > > I guess that that commit expected that NETDEV_DOWN event is fired before > > NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() > > is called only if (dev->features & NETIF_F_HW_ESP) != 0. > > > > Sabrina Dubroca identified steps to reproduce the same symptoms as below. > > > > echo 0 > /sys/bus/netdevsim/new_device > > dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) > > ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ > > spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ > > offload crypto dev $dev dir out > > ethtool -K $dev esp-hw-offload off > > echo 0 > /sys/bus/netdevsim/del_device > > > > Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after > > xfrm_dev_state_add() acquired a reference to "struct net_device". > > Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit > > when acquiring a reference to "struct net_device". > > > > Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") > > re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that > > commit for unknown reason chose to share xfrm_dev_down() between the > > NETDEV_DOWN event and the NETDEV_UNREGISTER event. > > I guess that that commit missed the behavior in the previous paragraph. > > > > Therefore, we need to re-introduce xfrm_dev_unregister() in order to > > release the reference to "struct net_device" by unconditionally flushing > > state and policy. > > > > Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 > > Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") > > Cc: Sabrina Dubroca > > Signed-off-by: Tetsuo Handa > > Now applied to the ipsec tree, thanks a lot! Thanks, I also didn't hear any bad news from our regression too. Thanks