CVE-2026-31495

What it actually does

This is an improper input validation flaw in the Linux kernel netfilter ctnetlink interface. Certain conntrack netlink attributes were not constrained by netlink policy checks before being processed, including TCP conntrack state, TCP window scale values, and conntrack filter/expectation flags. A local attacker able to send crafted NETLINK_NETFILTER messages can provide out-of-range values, including TCP window scale values above the valid maximum of 14, which may trigger undefined kernel behavior such as invalid shift operations and potentially a kernel crash. The practical impact is local denial of service against the affected Linux host; the CVSS vector indicates local access, low complexity, low privileges, no user interaction, and high availability impact.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that rely on the affected kernel netfilter conntrack code, causing service interruption, workload disruption, and possible host reboot. The risk is most relevant for multi-user Linux systems, container hosts, Kubernetes nodes, CI runners, bastion hosts, and environments where untrusted users or containers may have network administration capabilities. The vulnerability is not currently listed in CISA KEV, has very low EPSS, no known exploit maturity, and no ransomware association reported, so broad opportunistic exploitation is less likely; however, because it is a kernel-level availability issue, exposed shared-hosting or containerized environments should still prioritize remediation.

How an attack unfolds

An attacker first needs local execution on an affected Linux system, or execution inside a container or namespace configuration that allows interaction with NETLINK_NETFILTER, typically through CAP_NET_ADMIN or permissive user/network namespace settings. The attacker opens a netlink socket to the netfilter subsystem and sends crafted ctnetlink messages that include malformed conntrack protocol information, filter flags, or expectation flags. In vulnerable kernels, some of these values are accepted beyond their valid ranges because validation is performed manually and incompletely rather than by netlink policy enforcement. When the kernel later uses these malformed values, such as an excessive TCP window scale value used in a 32-bit shift operation, the kernel can encounter undefined behavior, warnings, oops conditions, or a panic. The result is denial of service through host instability or crash rather than data theft or privilege escalation based on the information currently available.

How to fix it

Upgrade affected Linux kernel packages to a vendor-supported version that includes the netfilter ctnetlink policy range-checking fix. Because no exact fixed versions were provided, use distribution advisories and kernel changelogs to identify packages that reference this CVE or the fix described as "netfilter: ctnetlink: use netlink policy range checks." If immediate patching is not possible, reduce exploitability by restricting CAP_NET_ADMIN to trusted users and containers only, avoiding privileged containers, disabling or limiting unprivileged user namespaces where operationally feasible, enforcing container runtime security profiles, and limiting local shell access on shared systems. Systems that perform conntrack-heavy firewalling, NAT, container networking, or Kubernetes node networking should be patched through normal kernel maintenance and rebooted into the fixed kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. Validate with commands such as `uname -r` and distribution package tools, then compare against the vendor advisory or changelog for the ctnetlink range-checking fix. Review kernel package changelogs for references to this CVE, `ctnetlink`, `CTA_PROTOINFO_TCP_WSCALE_ORIGINAL`, `CTA_PROTOINFO_TCP_WSCALE_REPLY`, or `netfilter: ctnetlink: use netlink policy range checks`. After patching, reboot if required and verify the active kernel version changed. In a non-production test environment, a purpose-built NETLINK_NETFILTER validation test can confirm malformed ctnetlink attributes are rejected early with netlink policy errors rather than accepted or causing kernel warnings. Also verify that untrusted containers and users do not have CAP_NET_ADMIN unless explicitly required.

Typical attack path

1. Obtain local code execution on an affected Linux system, container host, or namespace-enabled environment.
2. Acquire the ability to send NETLINK_NETFILTER messages, commonly via CAP_NET_ADMIN or permissive unprivileged user/network namespace configuration.
3. Create a NETLINK_NETFILTER socket from a local process.
4. Send crafted ctnetlink conntrack, filter, or expectation messages with out-of-range attributes such as invalid TCP window scale, TCP state, or flag masks.
5. Trigger vulnerable netfilter conntrack processing paths that use the invalid values.
6. Cause kernel instability, warning/oops, panic, or host crash, resulting in denial of service.

How to detect it

Exploitation is local and may not leave application-layer network indicators. Focus on host telemetry, kernel logs, audit logs, and container runtime activity. Review `dmesg`, `/var/log/kern.log`, `/var/log/messages`, journald, crash dumps, and kernel panic records for netfilter, conntrack, ctnetlink, UBSAN, shift-out-of-bounds, oops, or panic events shortly before unexpected reboots or node failures. If auditd or eBPF telemetry is available, look for unexpected local processes creating `AF_NETLINK` sockets with `NETLINK_NETFILTER` and issuing `sendmsg` calls, especially from untrusted users, build jobs, containers, or processes that do not normally administer firewall or conntrack state. In containerized environments, correlate kernel crashes or node instability with containers granted `CAP_NET_ADMIN`, privileged mode, host networking, or user namespace creation. Because no public exploit artifacts or named threat actors are reported, detection should emphasize anomalous local netlink behavior and crash forensics rather than static malware indicators.

• netfilter: ctnetlink
• ctnetlink
• NETLINK_NETFILTER
• AF_NETLINK
• CTA_PROTOINFO_TCP_WSCALE_ORIGINAL
• CTA_PROTOINFO_TCP_WSCALE_REPLY
• CTA_PROTOINFO_TCP_STATE
• CTA_FILTER_ORIG_FLAGS
• CTA_FILTER_REPLY_FLAGS
• CTA_EXPECT_FLAGS
• UBSAN: shift-out-of-bounds
• shift exponent
• is too large for 32-bit type
• kernel BUG
• kernel panic
• Oops:
• nf_conntrack
• conntrack

What your security team should do

• Patch affected Linux kernels using vendor security updates and reboot into the fixed kernel, prioritizing multi-user systems, container hosts, Kubernetes nodes, and externally important service hosts.
• Inventory systems where untrusted users, build jobs, or containers can obtain CAP_NET_ADMIN or create user/network namespaces, and treat those systems as higher priority.
• Remove CAP_NET_ADMIN from containers and service accounts unless strictly required; avoid privileged containers by default.
• Review kernel logs for historical oops, panic, UBSAN, or netfilter/ctnetlink-related errors that may indicate attempted exploitation or stability impact.
• Enable or review audit logging for suspicious local creation and use of NETLINK_NETFILTER sockets by unexpected users or workloads.
• Where patching is delayed, apply compensating controls such as restricting local access, disabling unprivileged user namespaces where feasible, and enforcing container runtime profiles such as seccomp, AppArmor, or SELinux.
• Track vendor advisories because fixed kernel versions vary by distribution and backport policy.