CVE-2026-31752

What it actually does

This is an improper input validation flaw in the Linux kernel bridge code path for IPv6 Neighbor Discovery handling. The vulnerable br_nd_send() logic walks Neighbor Discovery options using length values supplied inside the packet. A malformed option can cause the parser to advance beyond the valid option area or read a Source Link-Layer Address option that is too short to contain an Ethernet address. The expected impact is local, low-privileged denial of service: a user or workload able to inject crafted traffic through a Linux bridge, such as via a veth, tap, container, VM, or bridged interface, may be able to trigger a kernel crash or other availability-impacting fault. The published CVSS vector indicates no expected confidentiality or integrity impact, but high availability impact.

Why it matters to the business

Affected Linux systems that use kernel bridging for containers, virtualization, virtual switches, network appliances, or host networking may be susceptible to crashes caused by malformed local network traffic. In practice, exploitation could interrupt workloads, disconnect VMs or containers, cause node reboots, or create repeated service outages until the kernel is patched or the attack path is blocked. The vulnerability is not currently listed in CISA KEV, has very low EPSS, no known public exploit maturity, and no ransomware association, so urgency is primarily highest for multi-tenant Linux hosts, container platforms, virtualization hosts, and systems where untrusted local users or workloads can send bridged IPv6 traffic.

How an attack unfolds

An attacker first needs local low-privileged access or control of a workload that can transmit packets through a Linux bridge. This could be a container, VM, namespace, tap interface, veth endpoint, or local account with access to a bridged network path. The attacker then crafts IPv6 Neighbor Solicitation traffic containing malformed Neighbor Discovery options, such as an option whose length causes parsing to move beyond the remaining option area or a Source Link-Layer Address option that is too short for an Ethernet address. When the Linux bridge code processes this traffic through br_nd_send(), the vulnerable parser may read invalid option data or walk beyond the intended option span. Successful exploitation is expected to produce a denial-of-service condition, most likely a kernel oops, panic, networking failure, or host instability, rather than data theft or code execution. Repeated packet transmission could be used to keep an affected host or network node unstable until patched or mitigated.

How to fix it

Apply a Linux kernel update from the relevant distribution, appliance, cloud image, or hardware vendor that includes the upstream fix described as validating Neighbor Discovery option lengths in br_nd_send(). No exact fixed package versions were provided in the input, so use vendor advisories and changelogs to identify the corrected kernel for each affected product line. After installing the fixed kernel, reboot systems as required so the patched kernel is actually running. Prioritize systems using Linux bridge functionality with untrusted or semi-trusted workloads, including container hosts, Kubernetes nodes, virtualization hosts, network appliances, lab platforms, and multi-tenant Linux systems. If immediate patching is not possible, reduce exposure by limiting untrusted workloads’ ability to send raw or crafted L2/IPv6 traffic, disabling unused IPv6 on bridged segments where operationally safe, segmenting untrusted tenants away from shared bridges, applying eBPF/nftables/tc filtering for malformed ICMPv6 Neighbor Discovery traffic where feasible, and restricting CAP_NET_RAW or equivalent packet-crafting capabilities in containers and local workloads.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that run a kernel version prior to the vendor-fixed build and use bridge interfaces, commonly visible through commands such as ip link show type bridge, bridge link, or distribution-specific network configuration. Confirm remediation by verifying that the running kernel, not just the installed package, is the fixed vendor version after reboot. Review vendor kernel changelogs or source package metadata for wording similar to "bridge: br_nd_send: validate ND option lengths". Functional validation can include checking that bridged networking still operates normally after the update and, in a controlled test environment only, verifying that malformed IPv6 Neighbor Discovery packets are dropped or handled without kernel warnings, oopses, panics, or host instability. Also confirm that mitigations such as IPv6 filtering, container capability restrictions, or bridge segmentation remain in place where patching is delayed.

Typical attack path

1. Gain local low-privileged access or control of a workload attached to a Linux bridge, such as a container, VM, namespace, tap, or veth interface.
2. Identify that IPv6 Neighbor Discovery traffic can traverse the bridged interface.
3. Craft an IPv6 Neighbor Solicitation packet with malformed Neighbor Discovery option lengths, including an overlong option span or an undersized Source Link-Layer Address option.
4. Transmit the malformed packet through the bridge so the Linux kernel bridge path processes it in br_nd_send().
5. Trigger invalid option parsing, potentially causing a kernel oops, panic, networking disruption, or host crash.
6. Repeat transmission if necessary to sustain denial of service against the affected host or bridged network service.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, journald, syslog, crash dumps, and host monitoring around unexplained reboots, kernel oopses, panics, or network outages on systems using Linux bridge interfaces. Focus on /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg captures, kdump/vmcore analysis, hypervisor or container node event logs, and uptime/reboot records. Look for stack traces or warnings that include br_nd_send, Linux bridge code, IPv6 Neighbor Discovery, ICMPv6 Neighbor Solicitation handling, or faults immediately preceded by unusual ICMPv6 type 135 traffic on bridged interfaces. Network detection can look for malformed IPv6 Neighbor Discovery options on bridged segments, especially Neighbor Solicitation packets with invalid option lengths, zero-length options, option lengths that exceed the remaining payload, or Source Link-Layer Address options too short to contain a MAC address. Because this issue is expected to cause denial of service rather than persistent compromise, durable artifacts may be limited to crash logs, kernel traces, packet captures, and monitoring evidence of abrupt node failure.

• br_nd_send
• bridge: br_nd_send
• RIP: br_nd_send
• Call Trace: br_nd_send
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• Oops:
• IPv6 Neighbor Solicitation
• ICMPv6 type 135
• Source Link-Layer Address option
• ND option length 0
• Neighbor Discovery option length exceeds remaining payload
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/vmcore

What your security team should do

• Prioritize patching Linux bridge hosts that run untrusted containers, VMs, network namespaces, or user workloads, even though current EPSS is low and there is no KEV listing.
• Identify all systems using Linux bridge functionality, especially container platforms, virtualization hosts, network appliances, and multi-tenant Linux servers.
• Update to the vendor-fixed kernel and reboot to ensure the patched kernel is active.
• Restrict packet-crafting capabilities for untrusted workloads, including CAP_NET_RAW and equivalent privileges, where not operationally required.
• Monitor kernel logs and crash telemetry for oops, panic, or fault traces referencing br_nd_send or bridge Neighbor Discovery handling.
• Consider temporary IPv6 Neighbor Discovery filtering on bridged interfaces where feasible and tested, particularly on shared or untrusted bridge segments.
• Review incident history for unexplained Linux host crashes or network node instability since publication, especially on systems with bridged IPv6 traffic.
• Track vendor advisories for exact fixed kernel versions because no fixed versions were supplied in the source data.