From: Pablo Neira Ayuso <pablo@netfilter.org>
To: netfilter-devel@vger.kernel.org
Cc: davem@davemloft.net, netdev@vger.kernel.org, kuba@kernel.org,
pabeni@redhat.com, edumazet@kernel.org, horms@kernel.org,
fw@strlen.de, ja@ssi.bg
Subject: [PATCH net 11/12] netfilter: xt_recent: do not call remove_proc_entry() under recent_lock
Date: Thu, 5 Nov 2026 13:45:35 +0100 [thread overview]
Message-ID: <20261105124536.1009301-12-pablo@netfilter.org> (raw)
In-Reply-To: <20261105124536.1009301-1-pablo@netfilter.org>
From: "Cen Zhang (Microsoft)" <cenzhang@linux.microsoft.com>
recent_proc_net_exit() removes the /proc/net/xt_recent/<name> entries of
a dying network namespace while holding spin_lock_bh(&recent_lock).
remove_proc_entry() may sleep: proc_entry_rundown() waits until every
task that is still inside the entry's file operations has left. A reader
of such an entry is counted in by proc_reg_read() before
recent_seq_start() takes recent_lock. So if a read is in flight when the
namespace is torn down, cleanup_net() sleeps in atomic context holding
the spinlock that the reader is spinning on, and neither side can ever
make progress.
An unprivileged user can trigger this from a user namespace by adding a
rule with the "recent" match and reading its proc file while the
namespace is being destroyed. As recent_lock is global, every later
attempt to take it spins forever too: the spinning can spread to all
CPUs, and network namespace teardown stops system-wide.
BUG: sleeping function called from invalid context at
kernel/sched/completion.c:116
#3: (recent_lock){+...}-{3:3}, at: recent_net_exit+0x2b/0x140
Workqueue: netns cleanup_net
Call Trace:
proc_entry_rundown+0x185/0x1b0
remove_proc_entry+0x21a/0x520
recent_net_exit+0x7f/0x140
cleanup_net+0x414/0x8f0
...
rcu: INFO: rcu_preempt self-detected stall on CPU
Call Trace:
queued_spin_lock_slowpath+0x313/0xc20
recent_seq_start+0x87/0x1b0
seq_read_iter+0x265/0x11e0
proc_reg_read+0x1ab/0x270
Fix by taking recent_mutex instead of recent_lock. According to
commit a0e889bb1bdc ("[NETFILTER]: recent match: fix "sleeping function
called from invalid context""), recent_mutex is the lock to use here: it
protects recent_net->tables and was introduced so that proc entries are
created and removed without recent_lock held, because those calls may
sleep. hashlimit_proc_net_exit() does the same for xt_hashlimit.
Fixes: 665e205c16c1 ("netfilter: xt_recent: fix namespace destroy path")
Cc: stable@vger.kernel.org
Cc: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Cen Zhang (Microsoft) <cenzhang@linux.microsoft.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_recent.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 55f1f2d89952..00cccf003cff 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -650,14 +650,15 @@ static void __net_exit recent_proc_net_exit(struct net *net)
/* recent_net_exit() is called before recent_mt_destroy(). Make sure
* that the parent xt_recent proc entry is empty before trying to
- * remove it.
+ * remove it. Use recent_mutex instead of recent_lock since
+ * remove_proc_entry() may sleep.
*/
- spin_lock_bh(&recent_lock);
+ mutex_lock(&recent_mutex);
list_for_each_entry(t, &recent_net->tables, list)
remove_proc_entry(t->name, recent_net->xt_recent);
recent_net->xt_recent = NULL;
- spin_unlock_bh(&recent_lock);
+ mutex_unlock(&recent_mutex);
remove_proc_entry("xt_recent", net->proc_net);
}
--
2.47.3
next prev parent reply other threads:[~2026-11-05 12:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 12:45 [PATCH net,v4 00/12] Netfilter/IPVS fixes Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 01/12] netfilter: nft_reject: prevent unbounded recursion in output hooks Pablo Neira Ayuso
2026-11-05 12:50 ` netdev-bot+sinfo
2026-11-05 12:54 ` Pablo Neira Ayuso
2026-11-06 20:40 ` patchwork-bot+netdevbpf
2026-11-05 12:45 ` [PATCH net 02/12] ipvs: Defer application parent freeing until after RCU readers Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 03/12] ipvs: fix protocol data lifetime during namespace teardown Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 04/12] netfilter: nf_dup: preserve guard across NFQUEUE reinjection Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 05/12] netfilter: flowtable: extend ct timeout of offloaded GRE flows Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 06/12] netfilter: nft_set_rbtree: check catchall_sync return before queue_done Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 07/12] netfilter: bridge: use DEBUG_NET_WARN_ON_ONCE in nf_ct_bridge_refrag() Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 08/12] netfilter: x_tables: check target name before accessing verdict Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 09/12] netfilter: nf_conntrack_sip: fix OOB read in ct_sip_parse_transport() Pablo Neira Ayuso
2026-11-05 12:45 ` [PATCH net 10/12] netfilter: nf_tables: fix memleak when rule deletion fails with hardware offload Pablo Neira Ayuso
2026-11-05 12:45 ` Pablo Neira Ayuso [this message]
2026-11-05 12:45 ` [PATCH net 12/12] netfilter: nat: zero newrange before filling it in Pablo Neira Ayuso
2026-11-05 23:48 ` [PATCH net,v4 00/12] Netfilter/IPVS fixes Jakub Kicinski
2026-11-06 11:30 ` Pablo Neira Ayuso
2026-11-06 11:42 ` Pablo Neira Ayuso
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=20261105124536.1009301-12-pablo@netfilter.org \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=ja@ssi.bg \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.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.