Netdev List
 help / color / mirror / Atom feed
From: Cen Zhang <zzzccc427@gmail.com>
To: steffen.klassert@secunet.com, herbert@gondor.apana.org.au
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	baijiaju1990@gmail.com, jjzuming@gmail.com, zzzccc427@gmail.com
Subject: [PATCH ipsec] xfrm: keep the mode module pinned until destroy_state returns
Date: Thu, 29 Oct 2026 11:19:11 +0800	[thread overview]
Message-ID: <pm-xfrm-core-objects-candidate-0003-v3-3f3e13b81234df0bb10f@gmail.com> (raw)

An IPTFS state keeps its mode module referenced while mode_data exists.
However, iptfs_destroy_state() drops that reference before returning to
xfrm_state_gc_destroy(), which has no reference covering the callback's
return path.

With CONFIG_XFRM_IPTFS=m and module unloading enabled, deleting the last
IPTFS SA can overlap with ordinary module removal in this order:

  XFRM GC worker                      rmmod xfrm_iptfs
  iptfs_destroy_state()
    free mode_data
    module_put(owner)
    <preempted>
                                      delete_module()
                                        xfrm_iptfs_fini()
                                          unregister mode callbacks
                                        free_module()
    resume in freed module text

An unload started after the put can finish before the callback resumes.
GC invokes the callback outside an RCU read-side critical section, after
its grace period. The RCU waits in mode unregistration and module
freeing therefore do not protect the callback. The GC mutex only
serializes GC with device state flushes. Resuming the callback can cause
an instruction-fetch fault in the freed module text.

The Oops below was observed on an earlier kernel with scheduling probes
holding the worker in module_put() after the decrement until ordinary
rmmod completed. The fixture created and deleted the SA over
NETLINK_XFRM.

Take an additional reference to the already pinned owner before calling
destroy_state(), and release it in XFRM core after the callback returns.
Cache the owner before the call so releasing the extra reference does
not need to access the callback table after the callback has finished.

Oops report as below:
    BUG: unable to handle page fault for address: ffffffffc0407455
    #PF: supervisor instruction fetch in kernel mode
    #PF: error_code(0x0010) - not-present page
    PGD 80a9067 P4D 80a9067 PUD 80ab067 PMD 0 
    Oops: Oops: 0010 [#1] SMP KASAN NOPTI
    CPU: 3 UID: 0 PID: 53 Comm: kworker/3:1 Not tainted 7.2.0-rc5-pmb-xfrm-functional-v1+ #11 PREEMPT(lazy) 
    Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    Workqueue: events xfrm_state_gc_task
    RIP: 0010:0xffffffffc0407455
    Code: Unable to access opcode bytes at 0xffffffffc040742b.
    RSP: 0018:ffff8881013e7aa0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffffffffc02199c0 RCX: ffffffff816fc84e
    RDX: ffff8881013c0000 RSI: 0000000000000000 RDI: ffffffff86338344
    RBP: ffff8881013e7ba8 R08: 0000000000000001 R09: 0000000000000001
    R10: ffffffff893e0257 R11: ffff8881013c0000 R12: ffff888107e9ec00
    R13: ffff888102b07980 R14: ffff888107412ec0 R15: ffff8881013e7ae0
    FS:  0000000000000000(0000) GS:ffff8881fd929000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffc040742b CR3: 00000000080a6006 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? pmbd_gate_maybe+0x47/0x60
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? lock_is_held_type+0x8f/0x100
     xfrm_state_gc_task+0x17e/0x790
     ? lock_acquire+0x17b/0x2f0
     ? __pfx_xfrm_state_gc_task+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? lock_release+0xc8/0x280
     ? srso_alias_return_thunk+0x5/0xfbef5
     process_one_work+0x908/0x19c0
     ? __pfx_process_one_work+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? lock_is_held_type+0x8f/0x100
     ? srso_alias_return_thunk+0x5/0xfbef5
     worker_thread+0x65c/0xe40
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __kthread_parkme+0x175/0x220
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __pfx_worker_thread+0x10/0x10
     kthread+0x34f/0x460
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x659/0x940
     ? __pfx_ret_from_fork+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __switch_to+0x74f/0xf80
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    Modules linked in: [last unloaded: xfrm_iptfs]
    CR2: ffffffffc0407455
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:0xffffffffc0407455
    Code: Unable to access opcode bytes at 0xffffffffc040742b.
    RSP: 0018:ffff8881013e7aa0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffffffffc02199c0 RCX: ffffffff816fc84e
    RDX: ffff8881013c0000 RSI: 0000000000000000 RDI: ffffffff86338344
    RBP: ffff8881013e7ba8 R08: 0000000000000001 R09: 0000000000000001
    R10: ffffffff893e0257 R11: ffff8881013c0000 R12: ffff888107e9ec00
    R13: ffff888102b07980 R14: ffff888107412ec0 R15: ffff8881013e7ae0
    FS:  0000000000000000(0000) GS:ffff8881fd929000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffc040742b CR3: 00000000080a6006 CR4: 0000000000770ef0
    PKRU: 55555554
    Kernel panic - not syncing: Fatal exception
    Kernel Offset: disabled

Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl")
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Assisted-by: LLM

---
 net/xfrm/xfrm_state.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 0555e5d796ed..45a52771796b 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -596,8 +596,14 @@ EXPORT_SYMBOL(xfrm_state_free);
 static void xfrm_state_delete_tunnel(struct xfrm_state *x);
 static void xfrm_state_gc_destroy(struct xfrm_state *x)
 {
-	if (x->mode_cbs && x->mode_cbs->destroy_state)
+	if (x->mode_cbs && x->mode_cbs->destroy_state) {
+		struct module *owner = x->mode_cbs->owner;
+
+		/* The callback may drop the last module reference. */
+		__module_get(owner);
 		x->mode_cbs->destroy_state(x);
+		module_put(owner);
+	}
 	hrtimer_cancel(&x->mtimer);
 	timer_delete_sync(&x->rtimer);
 	kfree_sensitive(x->aead);

             reply	other threads:[~2026-10-29  3:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  3:19 Cen Zhang [this message]
2026-10-29  6:46 ` [PATCH ipsec] xfrm: keep the mode module pinned until destroy_state returns Leon Romanovsky

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=pm-xfrm-core-objects-candidate-0003-v3-3f3e13b81234df0bb10f@gmail.com \
    --to=zzzccc427@gmail.com \
    --cc=baijiaju1990@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jjzuming@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox