CVE-2026-98485 netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read

High 7.1 Published Updated

A crafted IPv6 packet can trigger an out-of-bounds read in the Linux kernel netfilter module, causing a kernel panic or information disclosure.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is CVE-2026-98485?

CVE-2026-98485 is a high-severity memory corruption vulnerability in Linux, published on 18 Oct 2026. Any signed-in user can exploit it over the network, with no action from the victim.

Official description

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: 1. Rejecting rules in rt_mt6_check() where IP6T_RT_FST_MASK is set but rtinfo->addrnr is zero. 2. 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.

Which versions are affected by CVE-2026-98485?

How do I fix CVE-2026-98485?

Apply the vendor's patch.

Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.

Is CVE-2026-98485 being exploited?

There is no known exploitation of CVE-2026-98485 in the wild and no public exploit code.

Sources

Also known as AZL-108650, BELL-CVE-2026-98485, DEBIAN-CVE-2026-98485, GHSA-mhfj-849g-frgh, UBUNTU-CVE-2026-98485.

Is CVE-2026-98485 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free