CVE-2026-31681

What it actually does

This is a Linux kernel netfilter flaw in the xt_multiport match implementation. The multiport v1 matcher interprets a non-zero port flag entry as the start of a port range and then reads the next ports[] entry as the range end. Before the fix, rule validation did not reject malformed encodings where the final entry was marked as a range start or where two range starts appeared consecutively. A local actor able to install crafted netfilter/iptables rules can cause the kernel to read past the valid multiport rule data when traffic is evaluated against the malformed rule. The expected impact is local denial of service through kernel fault, crash, or instability; confidentiality and integrity impact are not indicated by the advisory.

Why it matters to the business

Successful exploitation can take affected Linux systems offline or make networking unstable, which can disrupt hosted applications, container platforms, firewalls, gateways, and other workloads that rely on Linux packet filtering. The risk is most relevant where non-root users, containers, automation, or delegated administrators can obtain CAP_NET_ADMIN or otherwise modify iptables/netfilter rules. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported exploit maturity, so broad internet-scale exploitation is unlikely; however, the operational impact can be high on multi-tenant or containerized systems where local netfilter rule control is exposed.

How an attack unfolds

An attacker first needs local code execution or an administrative foothold that permits netfilter rule creation, typically root, CAP_NET_ADMIN, a privileged container, or a network namespace configuration that allows iptables rule changes. The attacker submits a crafted xt_multiport v1 rule whose internal range flags are malformed, such as marking the last port slot as the beginning of a range or placing range-start markers back to back. Because vulnerable kernels do not validate that encoding at rule insertion time, the malformed rule can be accepted. When a packet reaches the relevant hook and the kernel evaluates the rule, ports_match_v1() treats the malformed flag as a valid range and consumes a non-existent or invalid next entry. That out-of-bounds access can trigger a kernel oops, panic, or networking subsystem instability, causing denial of service until the system is recovered and the malformed rule is removed or the kernel is patched.

How to fix it

Upgrade affected Linux kernels to a vendor build that includes the netfilter fix titled "netfilter: xt_multiport: validate range encoding in checkentry." Because no exact fixed package versions were provided, use the relevant distribution or appliance vendor advisory to identify the patched kernel release, install it, and reboot into the updated kernel. As interim mitigations, restrict who can modify iptables/nftables/netfilter rules; remove unnecessary CAP_NET_ADMIN grants from users, services, and containers; avoid privileged containers unless required; disable unprivileged user namespaces where operationally feasible; and block loading or use of xt_multiport if it is not needed. Also review automation, firewall management tooling, and container orchestration policies that may allow untrusted workloads to create netfilter rules.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version, not only the installed package, matches a vendor release containing the xt_multiport checkentry validation fix. Review vendor changelogs or kernel package notes for the patch text "netfilter: xt_multiport: validate range encoding in checkentry." Confirm systems have been rebooted into the patched kernel using standard OS inventory commands. Validate exposure by identifying hosts where xt_multiport is loaded or multiport iptables rules are present and where untrusted principals can obtain CAP_NET_ADMIN. Review container, namespace, and service configurations for privileged mode or added NET_ADMIN capabilities. Do not validate by intentionally loading malformed kernel rules on production systems; if exploit reproduction is necessary, use an isolated lab host with crash capture enabled.

Typical attack path

1. Gain local access to an affected Linux system or workload with the ability to manage netfilter rules.
2. Obtain or abuse CAP_NET_ADMIN, root privileges, a privileged container, or a network namespace that allows iptables/netfilter updates.
3. Load a crafted xt_multiport v1 rule with invalid range encoding, such as a range-start flag in the final slot or consecutive range-start flags.
4. Generate or wait for network traffic that is evaluated against the malformed rule.
5. Trigger out-of-bounds rule parsing in the kernel during packet matching.
6. Cause kernel instability, oops, panic, or host/network denial of service.

How to detect it

Look for evidence of suspicious netfilter rule creation followed by kernel crashes or networking instability. Useful log sources include auditd execve records, sudo logs, shell history, EDR process telemetry, container runtime and Kubernetes audit logs, systemd journal, kernel ring buffer, kdump/vmcore data, and firewall management tool logs. Search for iptables or ip6tables invocations that use the multiport match, especially from unexpected users, containers, automation accounts, or recently compromised services. Because malformed encoding may be submitted through low-level netlink or setsockopt paths rather than a normal iptables CLI, also monitor for unexpected processes receiving CAP_NET_ADMIN or modifying netfilter state. Kernel logs and crash dumps are particularly important: exploitation is most likely to leave an oops, panic, general protection fault, or stack trace involving xt_multiport, ports_match_v1, netfilter, ip_tables, or ip6_tables. In containerized environments, review privileged container starts, added NET_ADMIN capabilities, and pods or containers that invoked iptables shortly before a host crash.

• xt_multiport
• ports_match_v1
• netfilter: xt_multiport
• iptables -m multiport
• ip6tables -m multiport
• --match multiport
• -m multiport
• xtables-multi
• CAP_NET_ADMIN
• privileged=true
• NET_ADMIN
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic
• Oops:
• ip_tables
• ip6_tables
• /proc/net/ip_tables_names
• /proc/net/ip6_tables_names

What your security team should do

• Prioritize patching Linux systems where containers, multi-tenant users, network appliances, CI runners, or delegated administrators can modify netfilter rules.
• Inventory hosts using iptables/ip6tables multiport matches or the xt_multiport module and correlate them with CAP_NET_ADMIN exposure.
• Remove CAP_NET_ADMIN from containers and services that do not strictly need it; eliminate privileged container configurations where possible.
• Restrict iptables, ip6tables, nft, and netfilter management to trusted administrative paths and monitor for unexpected rule changes.
• Review auditd, shell history, EDR, and orchestration logs for unusual iptables/ip6tables activity using the multiport match.
• Ensure kernel panic, kdump, and centralized logging are configured so suspected crashes preserve stack traces and command history.
• Treat unexplained kernel oops or panic events with xt_multiport or ports_match_v1 in the stack trace as potential exploitation until ruled out.