CVE-2026-98485

HIGH
MEDIUM Priority: 0.01 BB Relevance: 39/100
Published: 2026-10-18 Modified: 2026-10-24 First seen: 2026-10-29 Status: active

Attack Surface

Low Complexity No Interaction Conf. Impact

CVSS Vector Breakdown

AV: Local
AC: Low
PR: Low
UI: None
S: Unchanged
C: High
I: None
A: High

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.

Bug Bounty Relevance

39 / 100
✓ Low complexity
✓ No user interaction

CVSS Score

7.1 / 10.0 v3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

EPSS — Exploitation Probability

0.17%
Raw Score 0.001730
Percentile 6.7%
Date 2026-11-03

EPSS Trend

2026-11-03
0.00173
2026-11-02
0.00173
2026-11-01
0.00173
2026-10-31
0.00173
2026-10-30
0.00173
2026-10-29
0.00173
2026-10-28
0.00173

Intelligence Sources

nvd ref →