CVE-2026-45840
Received Received - Intake
Buffer Overflow in Open vSwitch Kernel Module

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: <TASK> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-05-27
AI Q&A
2026-05-27
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
openvswitch openvswitch *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's openvswitch component. It involves the handling of upcall PID arrays in vport netlink reply helpers. Specifically, the system allocates a fixed-size buffer for replies but allows a CAP_NET_ADMIN user to provide a PID array large enough to overflow this buffer. This overflow causes a failure in the nla_put() function and triggers a kernel BUG, potentially leading to a kernel panic.

The issue arises because ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, allowing oversized PID arrays. On systems with unprivileged user namespaces enabled, this can be exploited by unprivileged users via certain commands. The fix involves rejecting attempts to set more PIDs than the number of CPU IDs and pre-computing the worst-case reply size to prevent overflow.


How can this vulnerability impact me? :

This vulnerability can lead to a kernel BUG and a kernel panic, causing the affected system to crash or become unstable. An attacker with CAP_NET_ADMIN privileges, or on systems with unprivileged user namespaces enabled, potentially even an unprivileged user, could exploit this to disrupt normal system operations.

Such crashes can result in denial of service (DoS), impacting availability of services running on the affected system.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is caused by the ability to set an excessively large PID array size in Open vSwitch vport netlink replies, which can cause a kernel BUG and panic.

Immediate mitigation involves ensuring that attempts to set more PIDs than the number of CPU IDs (nr_cpu_ids) are rejected. This prevents buffer overflow in the reply buffer.

Updating the Linux kernel to a version where this issue is fixed (such as the one including the patch that rejects excessive PIDs and pre-computes the worst-case reply size) is recommended.

Additionally, restricting CAP_NET_ADMIN permissions to trusted users and disabling unprivileged user namespaces (if not needed) can reduce the risk of exploitation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart