CVE-2026-98485: netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6trt: fix zero-address non-strict match out-of-bounds read
rtmt6check() permits rules to be configured with rtinfo->addrnr == 0 even when address matching (IP6TRTFSTMASK) is requested.
In the IP6TRTFSTNSTRICT path, rtmt6() evaluates packet routing addresses against rtinfo->addrs[i] and terminates backwards at the bottom of the loop:
if (ipv6addrequal(ap, &rtinfo->addrs[i])) { i++; } if (i == rtinfo->addrnr) break;
When addrnr is 0, if the first packet address matches rtinfo->addrs[0], i is incremented to 1. Because i is now strictly greater than addrnr (0), the loop termination condition (i == rtinfo->addrnr) is bypassed and will never be satisfied.
If a crafted IPv6 packet contains matching routing addresses, i will advance past IP6TRTHOPS (16). The subsequent call to ipv6addrequal() reads beyond struct ip6trt, triggering UBSAN/KASAN out-of-bounds warnings or kernel panics.
Fix this by: 1. Rejecting rules in rtmt6check() where IP6TRTFSTMASK is set but rtinfo->addrnr is zero. 2. In rtmt6(), moving the termination condition (i < rtinfo->addrnr) into the for-loop header condition and removing the backwards break at the end of the loop body.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update rt_mt6_check() to reject zero-address non-strict match rules, and update rt_mt6() so the address loop terminates using i < rtinfo->addrnr before accessing rtinfo->addrs[i].
Linux kernel netfilter ip6t_rt rt_mt6_check() validation and rt_mt6() loop termination = Reject rules where IP6T_RT_FST_MASK is set and rtinfo->addrnr is 0; use i < rtinfo->addrnr as the for-loop condition and remove the backwards break
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed when they use the Linux kernel ip6t_rt matching code and have a rule that requests address matching with IP6T_RT_FST_MASK set while its addrnr value is zero. The vulnerable path is specifically the non-strict IP6T_RT_FST_NSTRICT matching path.
What is required to trigger the out-of-bounds read?
A crafted IPv6 packet must contain routing addresses that match the rule's address entries. When the first routing address matches addrs[0] while addrnr is zero, the loop can continue past IP6T_RT_HOPS (16), causing reads beyond the ip6t_rt structure and potentially UBSAN/KASAN warnings or a kernel panic.
What can be done before a kernel update is available?
Do not permit or retain ip6t_rt rules that request address matching with IP6T_RT_FST_MASK while addrnr is zero. Review existing relevant rules for that combination and remove or correct any such rule.
How can I determine whether a system has the risky rule configuration?
Inspect ip6t_rt rule configuration for rules with IP6T_RT_FST_MASK enabled and addrnr set to zero, particularly those using non-strict matching. Kernel UBSAN or KASAN out-of-bounds reports, or panics while processing matching IPv6 routing-address packets, are also indicators that the vulnerable path may have been reached.