CVE-2026-31531

What it actually does

This is a local Linux kernel availability flaw in the IPv4 nexthop rtnetlink path. When a user queries a large nexthop object or nexthop group using RTM_GETNEXTHOP, the kernel allocates a fixed-size socket buffer instead of sizing the netlink response dynamically. Large Equal-Cost Multi-Path nexthop groups can exceed that buffer and trigger a kernel warning in rtm_get_nexthop(). On systems configured to panic on kernel warnings, this can escalate from a warning splat to a host crash; otherwise, repeated triggering can still create operational instability and log noise. The issue does not provide confidentiality or integrity impact and is not known to enable privilege escalation.

Why it matters to the business

A local user or workload with sufficient ability to interact with routing netlink/nexthop functionality may be able to destabilize or crash affected Linux systems, causing service interruption. The risk is highest on multi-user systems, container hosts, network appliances, routing platforms, and systems where untrusted users or workloads can obtain network administration capabilities in a namespace. The CVSS score is moderate, EPSS is very low and stable, it is not in CISA KEV, and no public exploit maturity is reported, so this should be prioritized as a reliability hardening update rather than an emergency internet-facing exposure.

How an attack unfolds

An attacker first needs local code execution and the ability to issue relevant rtnetlink operations, typically requiring network administration capability in the initial namespace or in a network namespace. They create or cause the presence of an unusually large nexthop group, beyond sizes normally generated by standard iproute2 tooling. Because iproute2 currently enforces limits that prevent straightforward reproduction, exploitation would likely use custom netlink tooling or another component capable of constructing the required messages. The attacker then sends an RTM_GETNEXTHOP query for the oversized nexthop object. The vulnerable kernel attempts to build the response in a fixed-size NLMSG_GOODSIZE buffer, the calculated response does not fit, and the kernel emits a warning at net/ipv4/nexthop.c in rtm_get_nexthop(). If kernel.panic_on_warn is enabled, this warning can crash the system; otherwise, repeated attempts can cause denial-of-service symptoms through instability, excessive kernel logging, or watchdog/panic policies.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix changing rtm_get_nexthop() to allocate the netlink response dynamically with nh_nlmsg_size() and nlmsg_new(), and correcting nexthop group size calculations. No exact fixed package versions were provided, so use the appropriate distribution or appliance vendor advisory for the kernel package in use and confirm the changelog references this nexthop RTM_GETNEXTHOP fix. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN, disabling or tightly controlling unprivileged user namespaces where operationally feasible, avoiding untrusted workloads on affected hosts, and reviewing kernel.panic_on_warn settings because enabling it can turn this warning into a full system crash.

How to confirm the fix worked

Confirm the running kernel has the vendor backport or an upstream version containing the dynamic skb allocation fix for ipv4 nexthop RTM_GETNEXTHOP. Validate with vendor package metadata, kernel changelogs, or source inspection for rtm_get_nexthop() using nh_nlmsg_size() and nlmsg_new() rather than a fixed NLMSG_GOODSIZE allocation. On systems where testing is appropriate, perform any reproduction only in an isolated non-production host or VM and verify that querying large nexthop groups no longer produces kernel WARN messages. Also verify exposure-reduction controls: check whether unprivileged user namespaces are enabled, whether untrusted users or containers can obtain CAP_NET_ADMIN, and whether kernel.panic_on_warn is configured.

Typical attack path

1. Gain local execution on an affected Linux system or inside an environment that permits relevant network namespace/rtnetlink operations.
2. Obtain or abuse CAP_NET_ADMIN-equivalent capability in a namespace that allows nexthop manipulation or querying.
3. Construct a large IPv4 nexthop or nexthop group using custom netlink messages or a nonstandard management component.
4. Send an RTM_GETNEXTHOP request for the oversized nexthop object.
5. Trigger the fixed-size skb allocation failure path in rtm_get_nexthop(), causing a kernel warning and potential host crash when panic-on-warn or similar policies are enabled.
6. Repeat the operation to sustain availability impact or force service disruption.

How to detect it

Review kernel logs and centralized logging for warning splats from the IPv4 nexthop code path, especially messages referencing rtm_get_nexthop(), RTM_GETNEXTHOP, net/ipv4/nexthop.c, rtnetlink_rcv_msg, netlink_sendmsg, or WARNING entries around nexthop queries. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd, EDR telemetry, container runtime logs, and SIEM-ingested kernel logs. Correlate warning timestamps with local process execution, container activity, privilege changes, CAP_NET_ADMIN usage, creation of network namespaces, and unusual netlink/routing management operations. Investigate repeated warning splats or warnings followed by reboot, panic, watchdog reset, node eviction, routing daemon restart, or unexplained service outage. If audit rules are available, monitor privileged operations by tools or custom binaries interacting with NETLINK_ROUTE, iproute2-like behavior, and processes running with CAP_NET_ADMIN. No public threat actors or campaigns are currently identified for this issue in the provided intelligence.

• WARNING: net/ipv4/nexthop.c:3395
• rtm_get_nexthop
• RTM_GETNEXTHOP
• rtnetlink_rcv_msg
• netlink_rcv_skb
• netlink_unicast
• netlink_sendmsg
• ____sys_sendmsg
• ___sys_sendmsg
• __sys_sendmsg
• addattr_l ERROR: message exceeded bound of 1048
• net/ipv4/nexthop.c

What your security team should do

• Inventory Linux systems that support nexthop/routing functionality, especially container hosts, network appliances, routers, and multi-tenant compute systems.
• Prioritize kernel updates through normal maintenance windows, with higher urgency for systems where untrusted users or workloads can obtain CAP_NET_ADMIN or create network namespaces.
• Review and minimize CAP_NET_ADMIN grants to containers, services, and local users; remove broad privileged-container permissions where not required.
• Assess whether unprivileged user namespaces are necessary; disable or restrict them where feasible to reduce local kernel attack surface.
• Check kernel.panic_on_warn and similar panic policies on critical systems, because they can convert this warning condition into a full availability outage.
• Add monitoring for kernel warning splats involving rtm_get_nexthop, RTM_GETNEXTHOP, and net/ipv4/nexthop.c.
• Treat repeated occurrences as suspicious local activity and investigate the originating user, process, container, or namespace.
• Because EPSS is low, stable, and this is not KEV-listed, do not displace emergency patching for actively exploited remote vulnerabilities, but include this fix in the next kernel reliability/security rollout.