PULSE
FEED
ransompear reclama a Adobe Insurance Brokers, LLC · US · Financial Servicesransomhyflock reclama a gabonmeca.com leak incident · GA · Manufacturingransomhyflock reclama a dangvuongcac · VN · Not Foundransomn0n reclama a Company #103 · PT · Not Foundransomn0n reclama a Company #102 · Not Foundransomn0n reclama a Company #101 · Not Foundransomn0n reclama a Company #100 · Not Foundransomn0n reclama a Company #99 · Not Foundransomn0n reclama a TheHomeMag NorCal · US · Retail & E-Commerceransomclop reclama a LEGAL-RECORDS.US · US · Professional Servicesransomscarlettgroup reclama a nbcuniversal.com · US · Technologyransomn0n reclama a Xylanpicks · US · Not Foundransombravox reclama a GSE-M Technology Sdn. Bhd. · MY · Technologyransomemperador reclama a Bruin Group LLC · US · Otherransompear reclama a Adobe Insurance Brokers, LLC · US · Financial Servicesransomhyflock reclama a gabonmeca.com leak incident · GA · Manufacturingransomhyflock reclama a dangvuongcac · VN · Not Foundransomn0n reclama a Company #103 · PT · Not Foundransomn0n reclama a Company #102 · Not Foundransomn0n reclama a Company #101 · Not Foundransomn0n reclama a Company #100 · Not Foundransomn0n reclama a Company #99 · Not Foundransomn0n reclama a TheHomeMag NorCal · US · Retail & E-Commerceransomclop reclama a LEGAL-RECORDS.US · US · Professional Servicesransomscarlettgroup reclama a nbcuniversal.com · US · Technologyransomn0n reclama a Xylanpicks · US · Not Foundransombravox reclama a GSE-M Technology Sdn. Bhd. · MY · Technologyransomemperador reclama a Bruin Group LLC · US · Other
← All CVEs
CVE WatchOct 19, 2026

CVE-2026-98485

In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds rea

CVSS

—

No CVSS

EPSS

0.2%

p12

KEV

—

Exploit Today

4

0-100

Published: Oct 18, 2026 · Last modified: Oct 19, 2026

EPSS · 30d
0.2%EPSS · 30 days0.2%
2026-10-192026-10-20
Technical 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.

Official references
Related CVEs

No related CVEs by CWE or product.