AZL-108650

See a problem?
Import Source
https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-108650.json
JSON Data
https://api.osv.dev/v1/vulns/AZL-108650
Upstream
Published
2026-10-18T16:16:59Z
Modified
2026-10-19T14:16:31Z
Summary
CVE-2026-98485 affecting package kernel 6.6.157.1-1
Details

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.
References

Affected packages

Azure Linux:3 / kernel

Package

Name
kernel
Purl
pkg:rpm/azure-linux/kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Last Affected
6.6.157.1-1

Database specific

source
"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-108650.json"