CVE-2026-31674

What it actually does

This is a local Linux kernel memory-corruption flaw in the IPv6 netfilter routing-header match implementation, specifically ip6t_rt. During installation of an IPv6 firewall rule, the kernel failed to reject a malformed rt match rule whose addrnr value exceeded the fixed IP6T_RT_HOPS limit. Later, when packet matching evaluated that rule, rt_mt6() could index beyond the bounds of rtinfo->addrs[]. The likely result is an out-of-bounds kernel memory access that can disclose kernel memory or crash the system. Exploitation requires local privileges sufficient to install or influence IPv6 netfilter rules, commonly CAP_NET_ADMIN or equivalent privileges in a network namespace.

Why it matters to the business

An attacker who already has limited local access with the ability to manage firewall rules could use this flaw to read sensitive kernel memory or disrupt affected Linux systems by triggering a kernel crash. The risk is highest on multi-user Linux systems, container hosts, CI/CD runners, appliances, and environments where untrusted workloads can obtain CAP_NET_ADMIN or create user/network namespaces. It is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity in the supplied data, and has a very low, flat EPSS score, so broad internet-scale exploitation is unlikely; however, the operational impact can still be serious on shared or high-availability hosts.

How an attack unfolds

An attacker first obtains local code execution on an affected Linux system and gains the ability to install IPv6 netfilter rules, typically through CAP_NET_ADMIN, a privileged container, a permissive user-namespace configuration, or another local privilege boundary weakness. The attacker then submits a malformed ip6tables/x_tables IPv6 routing-header match rule with an addrnr value larger than the kernel's expected IP6T_RT_HOPS limit. Because vulnerable kernels do not validate this field during rule installation, the rule is accepted. When IPv6 traffic reaches the affected rule path, the kernel's rt_mt6() match logic uses the oversized value while accessing rtinfo->addrs[], resulting in an out-of-bounds kernel memory access. Depending on memory layout, kernel hardening, and the attacker's control over traffic and rule content, this may leak kernel memory or cause a denial of service through a kernel oops or panic.

How to fix it

Upgrade the Linux kernel to a vendor-supported build that includes the fix for the netfilter ip6t_rt addrnr bounds check in rt_mt6_check(), which rejects rt match rules whose addrnr exceeds IP6T_RT_HOPS at rule installation time. Because exact fixed versions were not provided, use distribution advisories from Red Hat, Debian, Ubuntu, SUSE, Amazon Linux, Oracle Linux, Alpine, container-host vendors, and appliance vendors to identify the corrected kernel package for each platform. After updating, reboot into the fixed kernel and confirm the running kernel version changed; merely installing the package is insufficient if the host is still booted into a vulnerable kernel. As interim mitigations, restrict CAP_NET_ADMIN to trusted users and workloads, avoid privileged containers, disable unneeded unprivileged user namespaces where operationally feasible, prevent untrusted workloads from managing netfilter rules, and unload or prevent use of legacy IPv6 x_tables routing-header matching if it is not required. These mitigations reduce exploitability but should not replace patching.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that an updated package is installed. Validate with commands such as uname -r, package-manager kernel inventory, and vendor advisory mapping. Check that systems have rebooted after patch deployment. Where source or changelog verification is available, confirm the kernel contains the netfilter change that rejects oversized addrnr values in rt_mt6_check(). Review whether the host exposes the vulnerable code path by checking for IPv6 netfilter usage, legacy ip6tables/x_tables rule support, and loaded modules related to IPv6 routing-header matching, such as ip6t_rt or related x_tables components. In higher-assurance environments, attempt to install a malformed rt match rule in a controlled test system running the candidate kernel and verify it is rejected rather than accepted. Also validate that untrusted users and containers cannot obtain CAP_NET_ADMIN or create network namespaces that can manipulate relevant firewall state unless explicitly intended.

Typical attack path

1. Gain local execution on an affected Linux host.
2. Obtain privileges sufficient to modify IPv6 netfilter rules, such as CAP_NET_ADMIN or equivalent capability inside a relevant network namespace.
3. Create or submit a malformed legacy ip6tables/x_tables rule using the IPv6 routing-header match with an oversized address count.
4. Ensure the malformed rule is installed successfully on a vulnerable kernel.
5. Generate IPv6 traffic that traverses the affected netfilter hook and triggers evaluation of the malformed rt match rule.
6. Cause an out-of-bounds kernel memory access, potentially leading to kernel memory disclosure or a system crash.

How to detect it

Look for evidence of suspicious local manipulation of IPv6 netfilter rules and signs of kernel memory faults. Relevant sources include auditd logs, sudo logs, shell history, EDR process telemetry, container runtime logs, Kubernetes audit logs, systemd journal, kernel ring buffer, and package/reboot history. Focus on executions of ip6tables, ip6tables-restore, nft in compatibility contexts, or custom binaries that call setsockopt/netfilter APIs while holding CAP_NET_ADMIN. Review audit records for changes to firewall rules by unexpected users, containers, service accounts, or automation. In kernel logs, search for crashes or memory-safety reports around ip6t_rt, rt_mt6, x_tables, ip6_tables, out-of-bounds access, general protection faults, kernel BUG, KASAN, page faults, oopses, or panics. On container hosts, correlate any kernel fault with privileged containers, containers granted CAP_NET_ADMIN, or pods using hostNetwork or elevated security contexts. Because exploitation may not leave a unique durable artifact, absence of logs does not prove absence of exploitation; combine log review with capability exposure review and kernel version validation.

• ip6t_rt
• rt_mt6
• x_tables
• ip6_tables
• ip6tables -m rt
• ip6tables-restore
• --rt-0-addrs
• CAP_NET_ADMIN
• general protection fault
• kernel BUG
• BUG: KASAN
• slab-out-of-bounds
• out-of-bounds
• kernel panic
• Oops

What your security team should do

• Inventory Linux systems that allow local shell access, run containers, host CI/CD jobs, or grant CAP_NET_ADMIN to workloads, and prioritize those for kernel updates.
• Patch affected Linux kernels using vendor-supported packages and reboot into the fixed kernel.
• Prioritize shared systems, container hosts, Kubernetes nodes, bastion hosts, research/HPC systems, and appliances where local privilege boundaries matter most.
• Review container and orchestration policies to remove CAP_NET_ADMIN from workloads that do not strictly require it.
• Disable privileged containers and restrict user/network namespace creation where feasible.
• Audit recent IPv6 netfilter rule changes, especially legacy ip6tables rules using the rt match module.
• Monitor for kernel oops, panic, general protection fault, KASAN, or slab out-of-bounds messages referencing ip6t_rt, rt_mt6, or x_tables.
• If patching must be delayed, restrict access to firewall-management commands and APIs, limit local user access, and consider disabling unused IPv6 routing-header match functionality.
• Because supplied intelligence shows low EPSS, no KEV listing, no ransomware association, and no known exploit maturity, treat this as a targeted local-risk issue rather than an active mass-exploitation emergency, while still patching promptly on exposed multi-tenant systems.