CVE-2026-31738

What it actually does

This is an improper input validation flaw in the Linux kernel VXLAN implementation. The vulnerable code path in vxlan_na_create() parses IPv6 Neighbor Discovery options using lengths supplied inside the packet. A malformed option can cause the parser to advance beyond the valid Neighbor Solicitation option area or read a source link-layer address option that is shorter than an Ethernet address. The primary technical impact is kernel memory misread and kernel crash, resulting in local denial of service. The published CVSS vector indicates local attack, low complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with VXLAN networking enabled may be susceptible to a local denial-of-service condition. In practical terms, a user or process with sufficient local access to reach the vulnerable VXLAN/Neighbor Discovery path could crash the host kernel, interrupting workloads, containers, virtual networking, or overlay-network-dependent services. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, has no known public exploit maturity, and has a very low stable EPSS score, so broad internet-scale exploitation is unlikely; however, multi-tenant Linux hosts, container platforms, virtualization nodes, and environments that rely heavily on VXLAN overlays should still prioritize patching because a kernel crash can cause material outage.

How an attack unfolds

An attacker first obtains low-privileged local access to a Linux system or to a context that can inject traffic into a vulnerable VXLAN/IPv6 Neighbor Discovery processing path. The attacker then crafts malformed Neighbor Discovery option data, such as an option whose encoded length causes the VXLAN parser to walk past the computed option boundary or a source link-layer address option that is too short for an Ethernet address. When the vulnerable kernel processes the malformed option in vxlan_na_create(), it may read beyond the expected option data or otherwise hit a kernel fault. Successful exploitation is expected to produce a denial of service, typically a kernel oops, panic, or host crash, rather than code execution or data theft. There are no named threat actors, KEV listing, or public exploit maturity reported for this issue in the provided intelligence.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for validating Neighbor Discovery option lengths in vxlan_na_create(). No exact fixed package versions were provided, so remediation should be tracked through vendor advisories for the affected kernel branch and distribution. Where immediate patching is not possible, reduce exposure by disabling unused VXLAN interfaces or the vxlan kernel module, limiting creation of network namespaces and VXLAN devices to trusted administrators, restricting CAP_NET_ADMIN and similar network-management capabilities, and isolating untrusted local users or workloads from overlay-network control and packet-injection paths. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the host continues running the old kernel.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, using standard platform tooling such as uname -r and the distribution package manager. Verify that the running kernel build is identified by the vendor as containing the vxlan_na_create() Neighbor Discovery option-length validation fix. Check whether VXLAN is in use with commands such as ip -d link show type vxlan and whether the vxlan module is loaded with lsmod or /proc/modules. After patching and rebooting, confirm that no vulnerable kernel remains booted, that VXLAN services operate normally, and that kernel logs do not show new oops, panic, KASAN, or general protection fault messages involving VXLAN or vxlan_na_create(). Avoid validating by sending malformed packets to production systems; use vendor version verification or controlled lab testing only.

Typical attack path

1. Gain low-privileged local access to a Linux host, container, namespace, or workload with a path to the affected VXLAN networking code.
2. Identify that VXLAN support is present and that IPv6 Neighbor Discovery processing can be reached on the target system.
3. Craft malformed Neighbor Discovery option data with invalid option lengths or an undersized source link-layer address option.
4. Inject or trigger processing of the malformed data through the VXLAN Neighbor Discovery handling path.
5. Cause the kernel to fault, oops, panic, or otherwise degrade availability, interrupting services running on the host.

How to detect it

Detection should focus on evidence of attempted or successful denial of service rather than data access, because the expected impact is kernel crash. Review kernel logs, persistent journal entries, console logs, crash dumps, kdump/vmcore artifacts, and hypervisor or node health telemetry for sudden reboots, kernel oopses, panics, KASAN reports, or general protection faults involving VXLAN, Neighbor Discovery, or vxlan_na_create(). In environments with audit logging, look for unusual local activity that creates network namespaces, VXLAN interfaces, or grants/uses CAP_NET_ADMIN shortly before a crash. Network packet captures, if available on relevant overlay interfaces, may show malformed IPv6 Neighbor Solicitation/Neighbor Discovery option data carried through VXLAN shortly before the event, but packet-level artifacts may not be retained after a panic. There are no public threat-actor-specific indicators or known exploit strings in the provided intelligence, so detections should be behavioral and crash-artifact based.

• vxlan_na_create
• RIP: .*vxlan_na_create
• Call Trace:.*vxlan
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• Oops:
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• vxlan:
• ip -d link show type vxlan
• /proc/modules
• vxlan

What your security team should do

• Patch affected Linux kernels through the appropriate OS or kernel vendor channel and reboot systems into the fixed kernel.
• Prioritize hosts where VXLAN is enabled, including container platforms, virtualization hosts, software-defined networking nodes, and overlay-network gateways.
• Inventory VXLAN exposure using ip -d link show type vxlan, lsmod, /proc/modules, and configuration-management data.
• Restrict CAP_NET_ADMIN, network namespace creation, and VXLAN device management to trusted administrative users and workloads.
• Disable unused VXLAN functionality or unload the vxlan module where operationally safe.
• Increase monitoring for kernel oops, panic, KASAN, BUG, and general protection fault events referencing vxlan or vxlan_na_create().
• Because the issue is not in KEV, has no known ransomware use, and has very low EPSS, handle it as availability-risk patching rather than an active mass-exploitation emergency unless local threat exposure is high.