PT-2026-128378
Published
2026-10-18
·
Updated
2026-10-18
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
- Rejecting rules in rt mt6 check() where IP6T RT FST MASK is set but rtinfo->addrnr is zero.
- In rt mt6(), 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.
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾