CVE-2025-68785: net: openvswitch: fix middle attribute validation in push_nsh() action
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix middle attribute validation in push_nsh() action
The push_nsh() action structure looks like this:
OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))
The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the
nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost
OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()
inside nsh_key_put_from_nlattr(). But nothing checks if the attribute
in the middle is OK. We don't even check that this attribute is the
OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()
calls - first time directly while calling validate_push_nsh() and the
second time as part of the nla_for_each_nested() macro, which isn't
safe, potentially causing invalid memory access if the size of this
attribute is incorrect. The failure may not be noticed during
validation due to larger netlink buffer, but cause trouble later during
action execution where the buffer is allocated exactly to the size:
BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]
Read of size 184 at addr ffff88816459a634 by task a.out/22624
CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)
Call Trace:
<TASK>
dump_stack_lvl+0x51/0x70
print_address_description.constprop.0+0x2c/0x390
kasan_report+0xdd/0x110
kasan_check_range+0x35/0x1b0
__asan_memcpy+0x20/0x60
nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]
push_nsh+0x82/0x120 [openvswitch]
do_execute_actions+0x1405/0x2840 [openvswitch]
ovs_execute_actions+0xd5/0x3b0 [openvswitch]
ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]
genl_family_rcv_msg_doit+0x1d6/0x2b0
genl_family_rcv_msg+0x336/0x580
genl_rcv_msg+0x9f/0x130
netlink_rcv_skb+0x11f/0x370
genl_rcv+0x24/0x40
netlink_unicast+0x73e/0xaa0
netlink_sendmsg+0x744/0xbf0
__sys_sendto+0x3d6/0x450
do_syscall_64+0x79/0x2c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Let's add some checks that the attribute is properly sized and it's
the only one attribute inside the action. Technically, there is no
real reason for OVS_KEY_ATTR_NSH to be there, as we know that we're
pushing an NSH header already, it just creates extra nesting, but
that's how uAPI works today. So, keeping as it is.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel Open vSwitch flaw in handling NSH push actions. A malformed nested attribute can pass validation and later cause an out-of-bounds memory read during action execution. The public record does not provide CVSS, impact rating, remote reachability, or active exploitation evidence.
Executive priority
Treat as a focused kernel maintenance item for systems using Open vSwitch. It is not currently supported by public active-exploitation evidence, but kernel memory-safety bugs in network datapath components deserve timely patching where the feature is enabled.
Technical view
The bug is missing validation of the middle OVS_KEY_ATTR_NSH attribute inside OVS_ACTION_ATTR_PUSH_NSH. The code double-unwraps nested netlink attributes with nla_data(), allowing incorrectly sized attributes to reach push_nsh() and trigger a KASAN-reported slab out-of-bounds read in nsh_hdr_from_nlattr.
Likely exposure
Likely exposure is Linux systems with the kernel Open vSwitch component enabled or used, especially environments processing NSH push actions. The source lists affected Linux version ranges and stable fixes, but does not define distribution package status or required attacker privileges.
Exploitation context
KEV is false, and the provided sources do not report exploitation in the wild. The crash trace shows a user process sending a generic netlink message that reaches Open vSwitch action execution; the sources do not prove remote exploitability.
Researcher notes
Key uncertainty is exploitability. The record shows an invalid memory access and validation bypass in nested netlink attribute parsing, but not privilege requirements, confidentiality impact, or reliable denial-of-service behavior. Reproduce only in controlled lab kernels using vendor-safe test guidance.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize Linux hosts running Open vSwitch or NSH-related datapath features.
Check distribution advisories for exact fixed package versions.
If Open vSwitch is unused, disable it following vendor guidance.
Validation and detection
Inventory kernel versions across Linux systems using Open vSwitch.
Check whether the openvswitch kernel module or OVS datapath is active.
Verify installed kernels include the relevant stable fix commit.
Review OVS management exposure and who can submit datapath actions.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68785 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.