Live › vulnerability › CVE-2026-98485
Go to dashboardThe netfilter ip6t_rt match module lets a rule with zero addresses and non-strict address matching loop past its array bounds. A crafted IPv6 packet with matching routing addresses makes the kernel read beyond the rule structure, causing kernel warnings or a crash.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with ip6t_rt netfilter matching enabled and IPv6 rules that use the rt match with address-matching options are exposed. Hosts that do not use IPv6 routing-header matches in ip6tables or nftables rules, or that run no netfilter IPv6 rules, can skip it.
No product ranges from the sources yet.
uname -r and compare it to the fixed kernel release in the linked kernel commits.rt match with --rt-type or --rt-segsleft address matching in ip6tables-save output, for example ip6tables-save | grep 'rt'.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read
rt_mt6_check() permits rules to be configured with rtinfo->addrnr == 0 even when address matching (IP6T_RT_FST_MASK) is requested.
In the IP6T_RT_FST_NSTRICT path, rt_mt6() evaluates packet routing addresses against rtinfo->addrs[i] and terminates backwards at the bottom of the loop:
if (ipv6_addr_equal(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 IP6T_RT_HOPS (16). The subsequent call to ipv6_addr_equal() reads beyond struct ip6t_rt, triggering UBSAN/KASAN out-of-bounds warnings or kernel panics.
Fix this by:
This page as .md · .json · in your agent: get_signal("CVE-2026-98485")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.