[PATCH net] net/sched: em_ipt: reject hook values >= NF_INET_NUMHOOKS

[PATCH net] net/sched: em_ipt: reject hook values >= NF_INET_NUMHOOKS

[hyunjungg]

From: Hyunjung Ko <hj351016@gmail.com>

em_ipt_change() reads the TCA_EM_IPT_HOOK netlink attribute into im->hook
as an unbounded u32, and check_match() later uses it as a shift amount:

	im->hook = nla_get_u32(tb[TCA_EM_IPT_HOOK]);
	...
	mtpar.hook_mask = 1 << im->hook;

TCA_EM_IPT_HOOK has no nla_policy range (it is a bare NLA_U32), and the
only range check on the hook lives in policy_validate_match_data(), which
rejects hook != NF_INET_PRE_ROUTING. That validator runs only for the
"policy" match; the "addrtype" match added by commit 0c4231c784b4 ("net:
sched: em_ipt: add support for addrtype matching") has its own validator
which does not look at the hook at all. A filter using match_name
"addrtype" can therefore carry an arbitrary hook value.

For hook >= 32 the "1 << im->hook" in check_match() is a shift that is
out of range for the 32-bit int, i.e. undefined behaviour; im->hook is
also passed unchecked to nf_hook_state_init() on the match path. Valid
hooks are only NF_INET_PRE_ROUTING..NF_INET_POST_ROUTING, so reject
anything >= NF_INET_NUMHOOKS when the attribute is parsed.

Reproduced on v7.3-rc3 (CONFIG_UBSAN=y) by adding a "basic" classifier
carrying an em_ipt "addrtype" ematch (match revision 1, nfproto AF_INET)
with TCA_EM_IPT_HOOK = 32:

  UBSAN: shift-out-of-bounds in net/sched/em_ipt.c:52:17
  shift exponent 32 is too large for 32-bit type 'int'

It requires CAP_NET_ADMIN (a tc filter add in a netns the caller controls).

Fixes: 0c4231c784b4 ("net: sched: em_ipt: add support for addrtype matching")
Cc: stable@vger.kernel.org # v5.3+
Signed-off-by: Hyunjung Ko <hj351016@gmail.com>
---
 net/sched/em_ipt.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 3650117da47f..c16469fb3e92 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -165,6 +165,11 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
 
 	im->match = match;
 	im->hook = nla_get_u32(tb[TCA_EM_IPT_HOOK]);
+	if (im->hook >= NF_INET_NUMHOOKS) {
+		ret = -EINVAL;
+		goto err;
+	}
+
 	im->nfproto = nfproto;
 	nla_memcpy(im->match_data, tb[TCA_EM_IPT_MATCH_DATA], mdata_len);
 
-- 
2.43.0

Re: [PATCH net] net/sched: em_ipt: reject hook values >= NF_INET_NUMHOOKS

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net/sched: em_ipt: reject hook values >= NF_INET_NUMHOOKS

[khj]

Hi,

Thanks. The issue was found by static analysis: a small checker that flags
values read from netlink attributes (nla_get_u8/u16/u32) that are then used
as a shift count without a range check. em_ipt's TCA_EM_IPT_HOOK was flagged
because it has no nla_policy bound and only the "policy" match validates the
hook, while the "addrtype" match does not. I then confirmed it at runtime
with UBSAN using the reproducer described in the commit message (a basic
classifier with an em_ipt "addrtype" ematch and TCA_EM_IPT_HOOK = 32).

Thanks,
Hyunjung Ko

2026년 10월 30일 (금) 오전 1:38, <netdev-bot+sinfo@kernel.org>님이 작성:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.