CVE-2026-45840

What it actually does

This flaw is a local denial-of-service vulnerability in the Linux kernel Open vSwitch netlink handling path. The affected code allows a user with CAP_NET_ADMIN in a network namespace to configure an oversized Open vSwitch upcall PID array. When the kernel later builds a vport netlink reply, it allocates a fixed-size socket buffer but attempts to serialize the full oversized PID array. The resulting size mismatch causes netlink attribute insertion to fail with -EMSGSIZE and triggers a kernel BUG_ON in ovs_vport_cmd_set(), which can crash the kernel and panic the host. On systems where unprivileged user namespaces are enabled, an otherwise unprivileged local user may be able to create a user and network namespace and obtain the required namespace-scoped CAP_NET_ADMIN capability, increasing practical exposure.

Why it matters to the business

Successful exploitation can abruptly crash an affected Linux host, causing workload interruption, dropped network connectivity, service downtime, and possible disruption to container or virtualization platforms that rely on Open vSwitch. The risk is highest on multi-user systems, container hosts, CI runners, developer workstations, and cloud or virtualization nodes where unprivileged user namespaces are enabled and Open vSwitch kernel functionality is available. The vulnerability is not listed in CISA KEV, has low EPSS at the time of assessment, and has no reported mature public exploitation in the provided data, but it remains operationally important because exploitation can cause full host denial of service.

How an attack unfolds

An attacker first obtains local code execution on an affected Linux system. If they do not already have CAP_NET_ADMIN, they attempt to use unprivileged user namespaces, for example by creating a new user and network namespace, to gain namespace-scoped administrative network capability. The attacker then interacts with the Open vSwitch generic netlink interface and creates or modifies an OVS vport using an intentionally oversized upcall PID array. The vulnerable kernel accepts the oversized array because the setter validates only that the value is a non-zero multiple of a 32-bit PID entry and does not enforce an upper bound. When the kernel prepares the vport netlink reply, it allocates a default-sized message buffer and attempts to serialize the oversized PID array into it. The serialization fails with -EMSGSIZE and the vulnerable path hits a BUG_ON condition in ovs_vport_cmd_set(), causing an invalid opcode/oops and potentially a kernel panic. The practical result is a local attacker-induced crash of the affected host.

How to fix it

Apply the vendor-provided Linux kernel update that includes the Open vSwitch fix to cap the upcall PID array to nr_cpu_ids and to pre-size vport replies correctly. No exact fixed package versions were provided in the input, so use distribution kernel advisories for the affected Linux release and update to the first kernel build containing the upstream fix for openvswitch upcall PID array bounds checking. Reboot into the updated kernel after installation, since kernel package installation alone does not remediate a running vulnerable kernel. As interim mitigations, disable unprivileged user namespaces where operationally feasible, restrict local shell access, limit container escape opportunities, prevent untrusted workloads from obtaining CAP_NET_ADMIN, and unload or avoid loading the Open vSwitch kernel module on systems that do not require it. On container and multi-tenant hosts, review workload capability grants and remove NET_ADMIN from containers unless explicitly required.

How to confirm the fix worked

Confirm the running kernel has been updated, not merely that a fixed package is installed. Validate with uname -a and the distribution package manager, then compare the running kernel build to the relevant vendor advisory. Check whether the Open vSwitch kernel module is present or loaded using lsmod | grep openvswitch and modinfo openvswitch where available. Verify unprivileged user namespace exposure by checking sysctl values such as kernel.unprivileged_userns_clone on distributions that provide it, and review user.max_user_namespaces. On fixed kernels, attempts to configure more upcall PIDs than nr_cpu_ids should be rejected cleanly rather than triggering a kernel BUG or panic. In production, avoid running public proof-of-concept crash tests on critical hosts; use a controlled test system with crash dump collection enabled if validation by negative testing is required.

Typical attack path

1. Gain local ability to execute code on an affected Linux system.
2. Determine whether Open vSwitch kernel support is present or loadable and whether OVS generic netlink operations are reachable.
3. If necessary, create a new user and network namespace to obtain namespace-scoped CAP_NET_ADMIN on systems that permit unprivileged user namespaces.
4. Send crafted Open vSwitch vport netlink mutation requests containing an oversized upcall PID array.
5. Trigger generation of the vport netlink reply path that attempts to serialize the oversized array into an undersized skb.
6. Cause nla_put() to fail with -EMSGSIZE and trigger BUG_ON in ovs_vport_cmd_set().
7. Crash the kernel or induce a kernel panic, causing local denial of service.

How to detect it

Look for evidence of kernel oops, BUG, invalid opcode, or panic events involving Open vSwitch vport handling. Primary log sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, crash dump metadata, kdump/vmcore records, and centralized EDR or SIEM telemetry that collects kernel logs. Relevant artifacts include stack traces referencing ovs_vport_cmd_set, ovs_vport_get_upcall_portids, ovs_vport_set_upcall_portids, ovs_vport_cmd_msg_size, nla_put, genl_family_rcv_msg_doit, genl_rcv_msg, netlink_sendmsg, or openvswitch/datapath.c. Correlate kernel crash times with local process execution, recent namespace creation, use of unshare, container launches with NET_ADMIN, ovs-vsctl or custom netlink tooling, and audit logs showing clone/unshare with CLONE_NEWUSER or CLONE_NEWNET. If auditd or eBPF telemetry is available, search for untrusted users executing unshare -Urn or processes opening generic netlink sockets shortly before the crash. Because exploitation is a crash condition, the strongest evidence is usually pre-crash kernel logs plus a vmcore showing the vulnerable Open vSwitch call path; absence of logs does not rule out exploitation if the host panicked before logs were flushed.

• kernel BUG at net/openvswitch/datapath.c
• BUG: kernel NULL pointer dereference
• Oops: invalid opcode
• Kernel panic - not syncing: Fatal exception
• RIP: 0010:ovs_vport_cmd_set
• ovs_vport_cmd_set+
• ovs_vport_get_upcall_portids
• ovs_vport_set_upcall_portids
• ovs_vport_cmd_msg_size
• nla_put
• -EMSGSIZE
• genl_family_rcv_msg_doit
• genl_rcv_msg
• netlink_sendmsg
• openvswitch:
• unshare -Urn
• CLONE_NEWUSER
• CLONE_NEWNET
• CAP_NET_ADMIN
• /var/crash
• /proc/sys/kernel/unprivileged_userns_clone
• /proc/sys/user/max_user_namespaces

What your security team should do

• Prioritize kernel updates on container hosts, virtualization nodes, Open vSwitch gateways, CI runners, shared development systems, and any multi-user Linux systems where unprivileged user namespaces are enabled.
• Reboot systems after applying the patched kernel and verify the active running kernel version is the fixed build.
• Temporarily disable unprivileged user namespaces where business operations allow, especially on shared systems exposed to untrusted local users or workloads.
• Audit containers, services, and automation jobs for CAP_NET_ADMIN or equivalent network administration privileges and remove them where not strictly required.
• Inventory systems with the openvswitch kernel module loaded or installed and treat those as the primary exposure set.
• Enable or verify kernel crash logging, persistent journald storage, kdump, and centralized collection of kernel oops/panic messages to support post-incident analysis.
• Monitor for kernel logs showing ovs_vport_cmd_set, openvswitch datapath BUGs, oversized netlink failures, or crashes following namespace creation by untrusted users.
• Because this issue is not in KEV and has low EPSS in the provided data, prioritize remediation based on local attacker exposure and operational criticality rather than internet-facing exploitability.