From: Steffen Klassert <steffen.klassert@secunet.com>
To: Chengfeng Ye <nicoyip.dev@gmail.com>
Cc: 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>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH] xfrm: serialize state GC with device state flush
Date: Mon, 24 Aug 2026 07:00:01 +0200 [thread overview]
Message-ID: <aovP0ZKcUaQlQryp@secunet.com> (raw)
In-Reply-To: <20260730103543.2077749-1-nicoyip.dev@gmail.com>
On Thu, Jul 30, 2026 at 06:35:43PM +0800, Chengfeng Ye wrote:
> The deferred-device pass in xfrm_dev_state_flush() finds states under
> xfrm_state_dev_gc_lock, but drops the lock before calling
> xfrm_dev_state_free() because the driver callback may sleep. The device
> GC list does not hold an xfrm_state reference, so the state GC worker can
> destroy the same state concurrently.
>
> The race can proceed as follows:
>
> CPU 0 CPU 1
> find x on the device GC list
> drop xfrm_state_dev_gc_lock
> read x->xso.dev
> xfrm_state_gc_destroy(x)
> xfrm_dev_state_free(x)
> xfrm_state_free(x)
> continue xfrm_dev_state_free(x)
>
> Both paths can invoke the driver callback and drop the device reference.
> CPU 0 can also access the xfrm_state after CPU 1 has freed it.
>
> KASAN reported:
>
> BUG: KASAN: slab-use-after-free in xfrm_dev_state_free+0x24c/0x2a0
> Read of size 8 at addr ffff88810bbaa960 by task poc/102
>
> Call Trace:
> xfrm_dev_state_free+0x24c/0x2a0
> xfrm_dev_state_flush+0x353/0x400
> xfrm_dev_event+0x26d/0x3a0
> notifier_call_chain+0xc0/0x280
> __dev_notify_flags+0x169/0x250
> netif_change_flags+0xe7/0x160
> dev_change_flags+0x96/0x220
> devinet_ioctl+0x7f4/0x1880
>
> Allocated by task 87:
> xfrm_state_alloc+0x1e/0x5c0
> xfrm_add_sa+0xe7f/0x5820
> xfrm_user_rcv_msg+0x4f3/0x940
>
> Freed by task 57:
> kmem_cache_free+0xcb/0x3d0
> xfrm_state_gc_task+0x4a8/0x650
> process_one_work+0x63a/0x1070
>
> Serialize xfrm_state destruction against the deferred-device pass with a
> mutex. Keep xfrm_state_dev_gc_lock limited to list operations and retain
> the existing callback and device-reference release ordering.
>
> Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Applied to the ipsec tree, thanks!
prev parent reply other threads:[~2026-08-24 5:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 10:35 [PATCH] xfrm: serialize state GC with device state flush Chengfeng Ye
2026-08-24 5:00 ` Steffen Klassert [this message]
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=aovP0ZKcUaQlQryp@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-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicoyip.dev@gmail.com \
--cc=pabeni@redhat.com \
--cc=stable@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 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.