CVE-2026-31682

What it actually does

This is a Linux kernel memory-safety flaw in the bridge Neighbor Discovery handling path. The vulnerable function parses IPv6 Neighbor Solicitation options from a socket buffer while assuming the option bytes are present in the linear portion of the packet buffer. A crafted non-linear packet can cause the kernel to read beyond the expected linear buffer while processing Neighbor Discovery options. The likely technical outcomes are kernel memory disclosure and/or a kernel fault leading to denial of service. The flaw affects systems using the Linux bridge code path, especially hosts acting as IPv6 bridges for virtual machines, containers, hypervisors, network appliances, or software-defined networking components.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that bridge IPv6 traffic, potentially interrupting workloads, virtual networks, container platforms, or network appliances. Because the issue is unauthenticated and network-triggerable, exposed bridged environments should treat it as operationally significant even though it is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score with no recent upward trend.

How an attack unfolds

An attacker who can send IPv6 traffic that reaches a vulnerable Linux bridge crafts a Neighbor Solicitation packet where the ICMPv6 header and target address are present but the Neighbor Discovery options reside outside the packet buffer’s linear area. When the Linux bridge code processes the request, it calls the affected Neighbor Discovery send path and parses the options as though they are linearly available. That parsing can read beyond the valid linear buffer. Depending on memory layout and kernel hardening, exploitation may result in a kernel warning, Oops, panic, bridge/network disruption, or possible disclosure of kernel memory. Repeated attempts could be used to cause recurring outages on systems forwarding bridged IPv6 traffic.

How to fix it

Upgrade to a Linux kernel build that includes the bridge fix for br_nd_send(), which linearizes the socket buffer before parsing Neighbor Discovery options. If vendor package fixed versions are not yet listed, obtain the latest security kernel from the operating system or appliance vendor and confirm that the patch for 'bridge: br_nd_send: linearize skb before parsing ND options' is included. Reboot into the fixed kernel after installation; live patching should only be considered sufficient if the vendor explicitly states this fix is covered. Where immediate patching is not possible, reduce exposure by limiting untrusted IPv6 access to bridged interfaces, filtering unnecessary ICMPv6 Neighbor Solicitation traffic at network boundaries where safe, disabling IPv6 on bridge segments that do not require it, or isolating untrusted tenants/workloads from shared Linux bridge domains. Avoid blanket ICMPv6 blocking on production IPv6 networks without testing, because Neighbor Discovery is required for normal IPv6 operation.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build containing the fix, not merely that an updated package is installed. Validate with package manager metadata, vendor advisories, kernel changelogs, or source commit inclusion for the br_nd_send linearization change. After reboot, verify the active kernel version with standard host inventory tooling and compare it to the vendor-fixed release. For exposure validation, inventory systems with Linux bridge interfaces, IPv6 enabled, and bridged VM/container/network appliance traffic. Review bridge configuration using tools such as 'ip link', 'bridge link', and distribution-specific network configuration. In test environments, carefully exercise IPv6 Neighbor Discovery across bridged interfaces and confirm there are no kernel warnings, Oops messages, or KASAN reports related to br_nd_send or Neighbor Discovery parsing.

Typical attack path

1. Identify or reach a network segment where a Linux host is operating as an IPv6 bridge.
2. Send crafted ICMPv6 Neighbor Solicitation traffic toward the bridged interface or bridged workload network.
3. Arrange packet layout so Neighbor Discovery options are present in a non-linear socket buffer rather than the linear packet area expected by the vulnerable code.
4. Trigger the bridge Neighbor Discovery send path to parse the malformed/non-linear option area.
5. Cause an out-of-bounds kernel read, potentially producing kernel memory disclosure or a kernel crash/panic.
6. Repeat traffic if the attacker’s goal is sustained denial of service.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, crash dumps, network telemetry, and packet captures from systems acting as Linux bridges. Primary host-side sources include journald, syslog, dmesg, kernel crash logs, kdump/vmcore records, hypervisor host logs, container node logs, and appliance support bundles. Search for kernel Oops, panic, KASAN, UBSAN, page fault, or general protection fault events that reference br_nd_send, bridge, ICMPv6, ndisc, or Neighbor Discovery processing. Network-side, review captures or IDS telemetry for unusual bursts of ICMPv6 Neighbor Solicitation packets, especially packets with extension headers, fragmentation, abnormal option lengths, malformed Neighbor Discovery options, or traffic sourced from untrusted bridge segments. Because no public exploit maturity is known and exploitation artifacts may be limited to crashes or anomalous packets, absence of logs is not proof of non-exploitation; prioritize correlation of kernel faults with inbound ICMPv6 type 135 traffic on bridged interfaces.

• br_nd_send
• BUG: KASAN: slab-out-of-bounds in br_nd_send
• BUG: KASAN: out-of-bounds in br_nd_send
• BUG: KASAN: use-after-free in br_nd_send
• general protection fault: 0000 [#
• Oops:
• kernel panic
• Call Trace:
• br_handle_frame
• br_dev_xmit
• icmpv6
• Neighbor Solicitation
• ICMPv6 type 135
• ndisc
• IPv6-ICMP

What your security team should do

• Prioritize patching Linux bridge hosts that carry untrusted or multi-tenant IPv6 traffic, including virtualization hosts, container nodes, network appliances, and SDN gateways.
• Track vendor advisories for the exact fixed kernel package and ensure systems are rebooted into the remediated kernel.
• Inventory bridge interfaces with IPv6 enabled and rank remediation by exposure to untrusted L2/L3 segments.
• Deploy temporary network controls to reduce untrusted ICMPv6 Neighbor Solicitation reachability where operationally safe.
• Monitor kernel logs and crash telemetry for bridge, ICMPv6, Neighbor Discovery, KASAN, Oops, or panic messages until all exposed systems are remediated.
• Because the vulnerability is not currently in KEV and EPSS remains low, use risk-based scheduling, but do not defer exposed bridge infrastructure that supports critical workloads.