From: Jamal Hadi Salim <jhs@mojatatu.com>
To: netdev@vger.kernel.org
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
Victor Nogueira <victor@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
sashiko-bot@kernel.org, hybris <hybris@mojatatu.ai>,
stable@vger.kernel.org
Subject: [PATCH net] net/sched: act_gate: reject oversized dumps instead of wrapping them
Date: Thu, 1 Oct 2026 06:00:54 -0400 [thread overview]
Message-ID: <QDISC-H19Z.v1.20261001053234@mojatatu.com> (raw)
This is a follow-up to commit cfa165cbfbed ("net/sched: act_gate: budget
the per-entry list in get_fill_size") caught by Sashiko.
cfa165cbfbed sized the add/get reply from the action's real dump but did
not bound the entry count. An oversized gate therefore installs and its
dump emits a structurally corrupt message instead of failing cleanly.
Sashiko also flagged the enlarged reply as potentially something that
will crash the kernel with a memory-amplification / OOM vector.
We were able to recreate this using panic_on_oom=1 (128 concurent
threads GET on a VM sized at 1024M). In the past we have used
panic_on_oom=1; however, I am weighing-in that: if i have to
create a crash using panic_on_oom=1 then that is a "hardening" issue
and therefore left to net-next. See the discussion with Jakub
(https://lore.kernel.org/netdev/20260914191108.55a1a4f1@kernel.org/).
Note: The issue is resolvable using an entry-count cap, but:
an entry-count cap would also reject gate configurations that work today,
so it cannot justify a stable backport - so policy cap is for net-next;
this patch closes only the malformed uAPI the sizing fix introduced.
parse_gate_list() accepts any number of TCA_GATE_ONE_ENTRY elements; the
only bound is the nlattr header, whose u16 nla_len caps the request at
~5460 minimal 12-byte entries. That is fine for the request, but
tcf_gate_dump() emits ~36 bytes per entry, so past ~1820 entries the
TCA_GATE_ENTRY_LIST nest exceeds U16_MAX and nla_nest_end() writes a
wrapped length. The enclosing TCA_ACT_OPTIONS and per-action nests wrap
the same way, and the outermost TCA_ACT_TAB wraps first, at ~1815
entries, so an oversized reply is already corrupt from there on.
Close those four wrap-capable nests with nla_nest_end_safe(). It returns
-EMSGSIZE instead of writing a wrapped length, and each site already has
an error label that trims and fails the dump. The output is byte
identical for every message that serializes; a message that would wrap
now fails through the same path that returned a clean error before
cfa165cbfbed, so no configuration that works today changes behavior.
Conditions to recreate the bug: CONFIG_NET_SCH_ACT_GATE=y; install a gate
with 1815 or more minimal TCA_GATE_ONE_ENTRY elements (12 bytes each on
the wire, only TCA_GATE_ENTRY_INTERVAL set) and dump it with
RTM_GETACTION. Up to 1814 entries the reply is well formed; from 1815 the
outermost TCA_ACT_TAB nest length wraps (1821 for the innermost
TCA_GATE_ENTRY_LIST). CONFIG_DEBUG_NET=y (default n) additionally trips a
WARN in nla_nest_end(). Installing the gate needs CAP_NET_ADMIN in a user
namespace; the RTM_GETACTION trigger needs no capability once the gate
exists.
Fixes: cfa165cbfbed ("net/sched: act_gate: budget the per-entry list in get_fill_size")
Reported-by: Sashiko (nipa) <sashiko-bot@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
net/sched/act_api.c | 9 ++++++---
net/sched/act_gate.c | 3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index e45a63be397c..c7e87491a9fc 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -549,7 +549,8 @@ tcf_action_dump_1(struct sk_buff *skb, struct tc_action *a, int bind, int ref)
goto nla_put_failure;
err = tcf_action_dump_old(skb, a, bind, ref);
if (err > 0) {
- nla_nest_end(skb, nest);
+ if (nla_nest_end_safe(skb, nest) < 0)
+ goto nla_put_failure;
return err;
}
@@ -1270,7 +1271,8 @@ int tcf_action_dump(struct sk_buff *skb, struct tc_action *actions[],
tcf_action_dump_1(skb, a, bind, ref);
if (err < 0)
goto errout;
- nla_nest_end(skb, nest);
+ if (nla_nest_end_safe(skb, nest) < 0)
+ goto nla_put_failure;
}
return 0;
@@ -1684,7 +1686,8 @@ static int tca_get_fill(struct sk_buff *skb, struct tc_action *actions[],
if (tcf_action_dump(skb, actions, bind, ref, false) < 0)
goto out_nlmsg_trim;
- nla_nest_end(skb, nest);
+ if (nla_nest_end_safe(skb, nest) < 0)
+ goto out_nlmsg_trim;
nlh->nlmsg_len = skb_tail_pointer(skb) - b;
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
index 6d6d45e03c07..14801c604bd9 100644
--- a/net/sched/act_gate.c
+++ b/net/sched/act_gate.c
@@ -654,7 +654,8 @@ static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
goto nla_put_failure;
}
- nla_nest_end(skb, entry_list);
+ if (nla_nest_end_safe(skb, entry_list) < 0)
+ goto nla_put_failure;
tcf_tm_dump(&t, &gact->tcf_tm);
if (nla_put_64bit(skb, TCA_GATE_TM, sizeof(t), &t, TCA_GATE_PAD))
--
2.43.0
next reply other threads:[~2026-10-01 10:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 10:00 Jamal Hadi Salim [this message]
2026-10-04 13:02 ` [PATCH net] net/sched: act_gate: reject oversized dumps instead of wrapping them netdev-bot+sashiko
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=QDISC-H19Z.v1.20261001053234@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=hybris@mojatatu.ai \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.org \
--cc=victor@mojatatu.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