* [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure
@ 2026-09-15 15:08 Nguyen Ngoc Thang
2026-09-18 15:15 ` Simon Horman
2026-09-18 23:40 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 3+ messages in thread
From: Nguyen Ngoc Thang @ 2026-09-15 15:08 UTC (permalink / raw)
To: netdev
Cc: Jamal Hadi Salim, Jiri Pirko, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Paul Blakey,
linux-kernel, Nguyen Ngoc Thang, syzbot+6cc37aba98dac721c415
flow_offload_alloc() returns NULL when the conntrack entry is dying
(e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation
fails; both are expected under load and neither is a kernel bug. This
path runs from softirq on every committed packet, so with
panic_on_warn=1 an unprivileged user can panic the box just by racing
a conntrack flush against a `tc ... action ct commit` classifier.
Reproduced with a custom repro under QEMU: a small, fixed set of UDP
flows through `tc filter ... action ct commit` on lo, raced against
threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits
WARNING: net/sched/act_ct.c:437 (tcf_ct_flow_table_add(), inlined
into tcf_ct_act() in this build) within ~15s on the unpatched kernel;
same setup is clean on the patched kernel. The fix itself is
behavior-preserving: both branches already did `goto err_alloc`
before and after, only the WARN is removed.
Fixes: 64ff70b80fd4 ("net/sched: act_ct: Offload established connections to flow table")
Reported-by: syzbot+6cc37aba98dac721c415@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6cc37aba98dac721c415
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
---
net/sched/act_ct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
index 9080cb386c16..55f3521edb4c 100644
--- a/net/sched/act_ct.c
+++ b/net/sched/act_ct.c
@@ -432,11 +432,10 @@ static void tcf_ct_flow_table_add(struct tcf_ct_flow_table *ct_ft,
if (test_and_set_bit(IPS_OFFLOAD_BIT, &ct->status))
return;
+ /* NULL if ct is dying (raced flush) or the atomic alloc failed. */
entry = flow_offload_alloc(ct);
- if (!entry) {
- WARN_ON_ONCE(1);
+ if (!entry)
goto err_alloc;
- }
if (tcp) {
ct->proto.tcp.seen[0].flags |= IP_CT_TCP_FLAG_BE_LIBERAL;
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure
2026-09-15 15:08 [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure Nguyen Ngoc Thang
@ 2026-09-18 15:15 ` Simon Horman
2026-09-18 23:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: Simon Horman @ 2026-09-18 15:15 UTC (permalink / raw)
To: Nguyen Ngoc Thang
Cc: netdev, Jamal Hadi Salim, Jiri Pirko, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Paul Blakey,
linux-kernel, syzbot+6cc37aba98dac721c415
On Tue, Sep 15, 2026 at 10:08:16PM +0700, Nguyen Ngoc Thang wrote:
> flow_offload_alloc() returns NULL when the conntrack entry is dying
> (e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation
> fails; both are expected under load and neither is a kernel bug. This
> path runs from softirq on every committed packet, so with
> panic_on_warn=1 an unprivileged user can panic the box just by racing
> a conntrack flush against a `tc ... action ct commit` classifier.
>
> Reproduced with a custom repro under QEMU: a small, fixed set of UDP
> flows through `tc filter ... action ct commit` on lo, raced against
> threads flooding bare ctnetlink CT_DELETE (flush) requests. Hits
> WARNING: net/sched/act_ct.c:437 (tcf_ct_flow_table_add(), inlined
> into tcf_ct_act() in this build) within ~15s on the unpatched kernel;
> same setup is clean on the patched kernel. The fix itself is
> behavior-preserving: both branches already did `goto err_alloc`
> before and after, only the WARN is removed.
>
> Fixes: 64ff70b80fd4 ("net/sched: act_ct: Offload established connections to flow table")
> Reported-by: syzbot+6cc37aba98dac721c415@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=6cc37aba98dac721c415
> Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure
2026-09-15 15:08 [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure Nguyen Ngoc Thang
2026-09-18 15:15 ` Simon Horman
@ 2026-09-18 23:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2026-09-18 23:40 UTC (permalink / raw)
To: Nguyen Ngoc Thang
Cc: netdev, jhs, jiri, davem, edumazet, kuba, pabeni, horms, paulb,
linux-kernel, syzbot+6cc37aba98dac721c415
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 15 Sep 2026 22:08:16 +0700 you wrote:
> flow_offload_alloc() returns NULL when the conntrack entry is dying
> (e.g. raced with a conntrack flush) or when the GFP_ATOMIC allocation
> fails; both are expected under load and neither is a kernel bug. This
> path runs from softirq on every committed packet, so with
> panic_on_warn=1 an unprivileged user can panic the box just by racing
> a conntrack flush against a `tc ... action ct commit` classifier.
>
> [...]
Here is the summary with links:
- [net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure
https://git.kernel.org/netdev/net/c/47abe7a5c4eb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-18 23:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-15 15:08 [PATCH net] net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure Nguyen Ngoc Thang
2026-09-18 15:15 ` Simon Horman
2026-09-18 23:40 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®