* [PATCH] net: sched: em_ipt: validate hook value from netlink
@ 2026-10-26 9:07 Fang Xieyan
2026-10-26 9:10 ` netdev-bot+sinfo
2026-10-26 9:30 ` Fang Xieyan
0 siblings, 2 replies; 3+ messages in thread
From: Fang Xieyan @ 2026-10-26 9:07 UTC (permalink / raw)
To: jhs, jiri
Cc: davem, edumazet, kuba, pabeni, horms, eyal.birger, netdev,
linux-kernel, liuwb, zhugl3
em_ipt_change() accepts the user-provided TCA_EM_IPT_HOOK value
without validating its range.
The value is later used in check_match() as "1 << im->hook". A hook
value of 32 or greater causes undefined behavior and may undermine the
xt match hook-mask validation. The value is also passed to
nf_hook_state_init() as a hook index.
Reject hook values outside the supported IPv4/IPv6 Netfilter hook
range after checking the required attributes, before loading the xt
match or allocating the match state.
Reviewed-by: Weibin Liu <liuwb@xiaopeng.com>
Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com>
---
net/sched/em_ipt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 3650117da..e4a8c1f0a 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -142,6 +142,9 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
!tb[TCA_EM_IPT_MATCH_DATA] || !tb[TCA_EM_IPT_NFPROTO])
return -EINVAL;
+ if (nla_get_u32(tb[TCA_EM_IPT_HOOK]) >= NF_INET_NUMHOOKS)
+ return -EINVAL;
+
nfproto = nla_get_u8(tb[TCA_EM_IPT_NFPROTO]);
switch (nfproto) {
case NFPROTO_IPV4:
--
2.50.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] net: sched: em_ipt: validate hook value from netlink
2026-10-26 9:07 [PATCH] net: sched: em_ipt: validate hook value from netlink Fang Xieyan
@ 2026-10-26 9:10 ` netdev-bot+sinfo
2026-10-26 9:30 ` Fang Xieyan
1 sibling, 0 replies; 3+ messages in thread
From: netdev-bot+sinfo @ 2026-10-26 9:10 UTC (permalink / raw)
To: Fang Xieyan
Cc: jhs, jiri, davem, edumazet, kuba, pabeni, horms, eyal.birger,
netdev, linux-kernel, liuwb, zhugl3
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.
- Whether the issue was actually triggered, or is only theoretical
(e.g. found by code inspection). If it was triggered please include
the symptoms, like the stack trace or error messages.
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] net: sched: em_ipt: validate hook value from netlink
2026-10-26 9:07 [PATCH] net: sched: em_ipt: validate hook value from netlink Fang Xieyan
2026-10-26 9:10 ` netdev-bot+sinfo
@ 2026-10-26 9:30 ` Fang Xieyan
1 sibling, 0 replies; 3+ messages in thread
From: Fang Xieyan @ 2026-10-26 9:30 UTC (permalink / raw)
To: netdev-bot+sinfo
Cc: jhs, jiri, davem, edumazet, kuba, pabeni, horms, eyal.birger,
netdev, linux-kernel, liuwb
Hi,
Thanks for the automated review. Here's the additional information:
**How the issue was discovered:**
Identified through automated security scanning tools during internal
security research, followed by manual code review to confirm the
vulnerability and assess its impact.
**Whether the issue was actually triggered:**
Yes, successfully reproduced using QEMU/KVM with a kernel built with
CONFIG_UBSAN=y, CONFIG_UBSAN_TRAP=y, and CONFIG_UBSAN_SHIFT=y.
**Symptoms:**
The reproducer creates a TC basic filter with em_ipt match using addrtype
revision 1 and hook value 42 (out of valid NF_INET_* range 0-4). This
triggers the following kernel Oops in check_match():
Oops: invalid opcode: 0000 [#1] SMP NOPTI
RIP: 0010:check_match.cold+0x0/0x2
RCX: 000000000000002a <- 0x2a = 42 (the hook value from PoC)
Disassembly confirms the ud2 trap instruction at check_match.cold+0x0
corresponds to the UBSAN check for the shift operation "1 << im->hook".
Without UBSAN, on x86 the shift instruction may mask the count to low
5 bits, yielding hook_mask = 0x400, which does not overlap the standard
hook bits checked by the addrtype interface-limit validation.
Best regards,
Fang Xieyan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-26 9:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-26 9:07 [PATCH] net: sched: em_ipt: validate hook value from netlink Fang Xieyan
2026-10-26 9:10 ` netdev-bot+sinfo
2026-10-26 9:30 ` Fang Xieyan
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®