CVE-2025-40254: net: openvswitch: remove never-working support for setting nsh fields
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: remove never-working support for setting nsh fields
The validation of the set(nsh(...)) action is completely wrong.
It runs through the nsh_key_put_from_nlattr() function that is the
same function that validates NSH keys for the flow match and the
push_nsh() action. However, the set(nsh(...)) has a very different
memory layout. Nested attributes in there are doubled in size in
case of the masked set(). That makes proper validation impossible.
There is also confusion in the code between the 'masked' flag, that
says that the nested attributes are doubled in size containing both
the value and the mask, and the 'is_mask' that says that the value
we're parsing is the mask. This is causing kernel crash on trying to
write into mask part of the match with SW_FLOW_KEY_PUT() during
validation, while validate_nsh() doesn't allocate any memory for it:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)
RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]
Call Trace:
<TASK>
validate_nsh+0x60/0x90 [openvswitch]
validate_set.constprop.0+0x270/0x3c0 [openvswitch]
__ovs_nla_copy_actions+0x477/0x860 [openvswitch]
ovs_nla_copy_actions+0x8d/0x100 [openvswitch]
ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]
genl_family_rcv_msg_doit+0xdb/0x130
genl_family_rcv_msg+0x14b/0x220
genl_rcv_msg+0x47/0xa0
netlink_rcv_skb+0x53/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x280/0x3b0
netlink_sendmsg+0x1f7/0x430
____sys_sendmsg+0x36b/0x3a0
___sys_sendmsg+0x87/0xd0
__sys_sendmsg+0x6d/0xd0
do_syscall_64+0x7b/0x2c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The third issue with this process is that while trying to convert
the non-masked set into masked one, validate_set() copies and doubles
the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested
attributes. It should be copying each nested attribute and doubling
them in size independently. And the process must be properly reversed
during the conversion back from masked to a non-masked variant during
the flow dump.
In the end, the only two outcomes of trying to use this action are
either validation failure or a kernel crash. And if somehow someone
manages to install a flow with such an action, it will most definitely
not do what it is supposed to, since all the keys and the masks are
mixed up.
Fixing all the issues is a complex task as it requires re-writing
most of the validation code.
Given that and the fact that this functionality never worked since
introduction, let's just remove it altogether. It's better to
re-introduce it later with a proper implementation instead of trying
to fix it in stable releases.
Security readout for executives and security teams
Plain-English summary
CVE-2025-40254 is a Linux kernel Open vSwitch flaw where malformed handling of an NSH set action can crash the kernel. The supplied sources describe reliability impact, not data theft. Business urgency depends on whether Linux systems run Open vSwitch with users or tooling able to submit these actions.
Executive priority
Prioritize patching for Open vSwitch infrastructure and affected appliances because a kernel crash can disrupt network services. Treat as lower urgency for Linux systems that do not run Open vSwitch or expose OVS configuration paths.
Technical view
Open vSwitch validates set(nsh(...)) using logic meant for different NSH layouts. Masked nested attributes can be misparsed, causing a NULL pointer dereference during validation. The kernel fix removes this never-working action support rather than repairing it in stable releases.
Likely exposure
Exposure is most likely on Linux systems using the kernel Open vSwitch module, especially network virtualization, SDN, NFV, or appliance environments. Exact affected and fixed kernel builds must be mapped against vendor kernel packages and the referenced stable commits.
Exploitation context
The bundle does not show CISA KEV listing, public exploitation, or exploit availability. The described failure mode is kernel crash during Open vSwitch action validation, implying denial-of-service risk where an actor can reach the relevant Open vSwitch control path.
Researcher notes
The root issue is invalid reuse of NSH key validation for set(nsh(...)) action layout, confusion between masked and is_mask semantics, and incorrect conversion of nested attributes. Sources do not provide CVSS, CWE, or confirmed exploitation.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Review Siemens SSA-253495 if using Siemens affected products.
Avoid relying on set(nsh(...)) Open vSwitch behavior; sources say it never worked.
Restrict who can configure Open vSwitch flows and datapath actions.
Check Linux distribution advisories for exact package versions.
Validation and detection
Inventory Linux hosts running Open vSwitch kernel modules.
Map running kernel package versions to vendor fixed releases.
Confirm whether NSH-related Open vSwitch actions are used operationally.
Review logs for kernel oops or crashes in openvswitch validation paths.
Verify vendor advisories for embedded or appliance Linux builds.
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-40254 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.