CVE-2026-31679

What it actually does

This is an improper input validation flaw in the Linux kernel Open vSwitch datapath. The vulnerable code accepted malformed OVS SET or SET_MASKED actions containing an MPLS key attribute with an unexpected payload length, even though later action handling expects a fixed-size struct ovs_key_mpls. A local attacker with the ability to submit Open vSwitch datapath configuration or flow actions, typically through Netlink and relevant network-administration privileges, may be able to trigger out-of-bounds kernel memory access, leading to kernel memory disclosure and/or a denial of service such as a kernel crash. The CVSS vector indicates local exploitation, low complexity, low privileges, no user interaction, high confidentiality impact, and high availability impact.

Why it matters to the business

Successful exploitation could crash affected Linux systems or expose sensitive kernel memory, disrupting hosts that rely on Open vSwitch for virtualization, container networking, SDN, NFV, or cloud networking. The risk is highest on systems where Open vSwitch is installed, the kernel openvswitch module is loaded, and lower-trust users, containers, or automation have network-administration capabilities. Current public signals indicate low exploitation likelihood: EPSS is approximately 0.00117 with no meaningful 30-day increase, there is no known public exploit maturity, and it is not listed in CISA KEV or known ransomware use.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient privileges to interact with the Open vSwitch kernel datapath, commonly CAP_NET_ADMIN or equivalent rights in a relevant network namespace. The attacker then crafts an Open vSwitch action through the Netlink interface that uses OVS_ACTION_ATTR_SET or OVS_ACTION_ATTR_SET_MASKED with OVS_KEY_ATTR_MPLS but supplies an MPLS payload whose length does not match the fixed-size MPLS key structure expected by the kernel. On vulnerable kernels, validation may accept this malformed action. When the datapath later processes the action, it may interpret the malformed data as a fixed-size MPLS key, causing invalid memory access. Depending on kernel build, memory layout, and runtime conditions, this can result in kernel memory exposure, a crash, or other availability-impacting behavior.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the Open vSwitch fix to validate MPLS SET and SET_MASKED payload lengths and reject non-matching struct ovs_key_mpls sizes. No exact fixed package versions were provided in the input, so use the security advisory from the relevant Linux distribution or kernel provider and verify that the patch titled along the lines of 'openvswitch: validate MPLS set/set_masked payload length' is included. Where immediate patching is not possible, reduce exposure by disabling or unloading the openvswitch kernel module where it is not required, restricting Open vSwitch administration to trusted users only, removing CAP_NET_ADMIN from untrusted containers and services, disabling unneeded unprivileged user namespace patterns that grant network administration in isolated namespaces, and limiting local shell access on systems running Open vSwitch.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not just the installed package, has been updated or backported with the Open vSwitch MPLS payload-length validation fix. Use distribution package metadata, changelogs, vendor OVAL/vulnerability feeds, or kernel source package changelogs to confirm inclusion of the fix. Check whether exposure remains by determining if Open vSwitch is installed and whether the openvswitch kernel module is loaded using tools such as lsmod, modinfo, ovs-vsctl, and package inventory. Validate that untrusted users and containers do not have CAP_NET_ADMIN or equivalent permissions. After patching, reboot or otherwise ensure the fixed kernel is the active running kernel, then re-run vulnerability scanning and configuration checks.

Typical attack path

1. Gain local access to an affected Linux host or containerized environment where Open vSwitch functionality is available.
2. Obtain or already possess permission to configure network datapath state, such as CAP_NET_ADMIN or equivalent Open vSwitch/Netlink access.
3. Confirm that the Linux kernel Open vSwitch datapath is present and usable, for example by checking whether the openvswitch kernel module is loaded.
4. Craft a Netlink Open vSwitch flow/action message containing a SET or SET_MASKED action with OVS_KEY_ATTR_MPLS.
5. Set the MPLS action payload length to an invalid size that vulnerable validation logic accepts.
6. Submit the malformed action to the kernel datapath.
7. Trigger processing of the malformed action, potentially causing kernel memory disclosure or a denial of service.

How to detect it

There are no widely reported public exploitation artifacts for this issue, so detection should focus on signs of attempted malformed Open vSwitch action submission and resulting kernel instability. Review kernel logs, system journals, crash dumps, audit logs, and Open vSwitch logs around any unexpected host crashes, soft lockups, kernel oops events, or unusual Open vSwitch flow/action changes. Relevant log sources include journalctl/kern.log/messages, dmesg, kdump or crash dump repositories, auditd records for Netlink/network administration activity, sudo/session logs for ovs-* commands, and Open vSwitch logs such as ovs-vswitchd.log and ovsdb-server.log. Look for kernel traces that mention Open vSwitch functions, MPLS action handling, invalid Netlink attributes, general protection faults, BUG/WARNING splats, or crashes shortly after flow modification activity. In containerized environments, also review containers or processes granted CAP_NET_ADMIN and correlate their activity with kernel faults or Open vSwitch configuration changes.

• openvswitch
• OVS_KEY_ATTR_MPLS
• OVS_ACTION_ATTR_SET
• OVS_ACTION_ATTR_SET_MASKED
• ovs-vswitchd
• ovsdb-server
• kernel: Oops
• kernel: BUG:
• kernel: WARNING:
• general protection fault
• RIP: ovs_
• openvswitch:
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux hosts that run Open vSwitch in virtualization, container, SDN, NFV, or multi-tenant networking roles.
• Inventory systems with the openvswitch kernel module loaded and treat those as the primary exposure set.
• Remove CAP_NET_ADMIN and Open vSwitch administration rights from untrusted users, containers, CI jobs, and service accounts.
• If Open vSwitch is not required on a host, disable the service and unload or blacklist the openvswitch kernel module according to operational requirements.
• Monitor kernel logs for crashes, warnings, or oops traces involving Open vSwitch code paths, especially following local network configuration activity.
• Because EPSS is low, there is no KEV listing, and no exploit maturity is reported, handle this as a defense-in-depth kernel hardening issue unless the affected systems are multi-tenant or delegate network administration privileges broadly.