Linux Kernel OVS CVE-2025-40254: Removal of broken set(nsh) action

The Linux kernel has just closed a long‑standing correctness hole in its Open vSwitch (OVS) code: CVE‑2025‑40254 addresses a broken implementation of the set(nsh(... action that never worked as intended, caused kernel crashes during validation, and has now been removed from stable kernels rather than being patched in place.

Background / Overview​

Open vSwitch (OVS) implements many datapath and control-plane actions used in software-defined networking, including support for the Network Service Header (NSH) used in service chaining. The OVS datapath and netlink-based control paths must parse and validate nested attributes supplied from userspace (via ovs‑vsctl or other management tools) before manufacturing or applying flow actions. In this case, the problem was not a subtle off‑by‑one: the validation logic for set(nsh(... and masked set(nsh(... is fundamentally inconsistent with the memory layout the action actually uses, producing NULL dereferences when the kernel tried to write masks into memory that had not been allocated. The kernel community’s response was straightforward: because the feature “never worked” since its introduction, maintainers removed the flawed support from the kernel and documented the removal across multiple stable branches instead of attempting a risky, piecemeal fix. The Linux kernel CVE team assigned CVE‑2025‑40254 to the issue and linked the stable commits that remove the code paths.

---

What went wrong — technical anatomy​

NSH attributes, masks and memory layout​

NSH keys and NSH actions are represented by nested netlink attributes in OVS. There are two important variants to consider:

• push_nsh / match keys — these use one particular nested attribute layout and are validated by a known helper (nsh_key_put_from_nlattr.
• set(nsh(... actions — these use a different memory layout, and when they are masked the nested attributes are duplicated (value + mask), changing the expected size and parsing semantics.

The vulnerable code reused the same validation path for both cases, failing to account for the doubled nested-attribute size for masked sets and mixing up two different boolean signals:

• masked — a flag indicating that nested attributes include both a value and a mask (so twice the storage).
• is_mask — a flag that says the particular attribute being parsed is the mask portion.

This confusion produced incorrect size calculations and missing allocations. During validation the code could reach SW_FLOW_KEY_PUT and attempt to write mask data into memory that had not been allocated, leading to a NULL‑pointer dereference and kernel OOPS. The public trace posted in advisories shows a crash from nsh_key_put_from_nlattr invoked through validate_nsh and the netlink action parsing path.

Why fixing in place was ruled out​

Fixing the validation correctly would require a broad rewrite of the validation logic to support the distinct memory layout and to separate the semantic flags cleanly. Kernel maintainers judged that such a rewrite would be non‑trivial and risky to backport into stable kernels; since the set(nsh(... functionality had never worked since it was added, removal of the unsupported/incorrect code was the safest course for the stable trees. The linux‑cve‑announce summary and stable commit messages explain this choice and list the stable commits that removed the feature across branches.

---

Affected versions, timeline and fixes​

• The problematic code was introduced around the 4.15 timeframe (the initial commit introducing the functionality is noted in public trackers).
• The removal/fix landed as explicit commits in multiple stable series: examples listed by the kernel CVE announcement include fixes in 5.4.302, 6.6.118, 6.12.60, 6.17.10 and 6.18 branches — in short, modern stable kernels after those points no longer include the broken code paths.
• Public CVE records (NVD, SUSE, Debian/OSV and numerous aggregators) have indexed CVE‑2025‑40254 with descriptions matching the upstream reasoning and pointing administrators to stable commits.

If you maintain custom or vendor kernels, check your distribution advisory or kernel package changelog for the exact stable commit IDs referenced by the Linux kernel CVE announcement before assuming you are patched. The kernel community explicitly recommends updating to a patched stable kernel release rather than cherry‑picking individual commits.

---

Impact and exploitability — realistic assessment​

Primary impact: stability / availability​

The immediate and demonstrated impact is a kernel crash (NULL pointer dereference) during netlink action validation — an availability issue. Hosts that allow untrusted or insufficiently restricted users to issue OVS flow operations (for example, multi‑tenant NFV systems, cloud hypervisor hosts, or misconfigured management endpoints) are at risk of local or tenant‑adjacent denial‑of‑service. The trace in the advisories shows the kernel oops occurs while walking the netlink/ovs action parse path, so the vector is local or requires some level of authenticated management-plane access.

Secondary impact: incorrect flows and misbehavior​

Because the set(nsh(... support never worked properly, attempts to install masked NSH set actions might not only crash the kernel but even when they didn’t crash would have produced incorrect masks/values in flows — meaning installed flows “will most definitely not do what they are supposed to” according to upstream commentary. Misconfigured service-chaining behavior and traffic misdirection are plausible operational side‑effects in environments that attempted to use these actions.

Exploitation likelihood: moderate for local DoS, low for remote RCE​

• Remote exploitation without authenticated control access is unlikely: the netlink/genetlink flow insertion path requires local capabilities or management‑plane access to OVS. That reduces the surface for unauthenticated remote attackers.
• A determined local attacker, a malicious tenant with control-plane privileges, or a compromised management host could craft netlink messages that trigger the buggy validation path and crash the kernel.
• There is no credible public evidence that this bug can be turned into remote code execution; the documented effect is a crash and incorrect masking semantics. Treat escalation-to-RCE as speculative unless a PoC demonstrating memory‑corruption beyond the OOPS is published and independently verified.

---

Indicators of compromise and how to detect attempts​

Look for kernel oops traces and messages that match the stack walk present in public advisories. Useful detection signals include:

• dmesg or journalctl -k log entries referencing functions such as:
• nsh_key_put_from_nlattr
• validate_nsh
• validate_set / __ovs_nla_copy_actions
• Netlink/Geneve/genl call traces or repeated failure logs from ovs‑vswitchd or other OVS control components around the time of the kernel oops.
• Unexpected process crashes, reboots, or service restarts on hosts running OVS and exposing netlink controls to non‑privileged/insufficiently restricted users.

If you find an oops that matches the published stacktrace, preserve dmesg and vmcore (kdump) and treat the event as high priority for patching and forensics. The kernel’s OOPS output contains the instruction pointer and function names that are the best signal of the exact failing path.

---

Practical mitigation and remediation guidance​

Priority and triage​

• High priority: multi‑tenant hosts, NFV platforms, hypervisor hosts that run OVS and expose management-plane access across tenants, and any system where untrusted users or tenant code can request flow insertion.
• Medium priority: standalone servers with restricted admin access.
• Lower priority: systems that do not run Open vSwitch or where OVS control is fully locked to a single trusted administrator and management plane access is tightly controlled — although patching is still recommended.

Recommended immediate actions (copyable checklist)​

• Inventory servers that run OVS and list kernel versions: uname -r.
• Identify whether the kernel package changelog or vendor advisory includes CVE‑2025‑40254 or the upstream commit IDs that remove the set(nsh(... support.
• Apply vendor/kernel updates that include the fixes (prefer full stable kernel updates). Do not assume a kernel is safe without verifying package changelogs include the relevant stable commits.
• If you cannot patch immediately:
• Restrict access to OVS control plane interfaces (ovs‑vsctl, netlink sockets and management agents) to trusted administrators only.
• Limit who can send netlink/genetlink messages that modify flows (system policies, firewalling, process authentication, or SELinux/AppArmor rules).
• For containerized environments, ensure containers cannot access the host netlink sockets or the ovs control sockets.
• After patching, monitor kernel logs for residual oopses and validate that previously reproducible oopses are no longer present.

How to verify a successful remediation​

• Confirm that the running kernel package changelog references the stable commit(s) that remove or disable set(nsh(.... The kernel CVE announcement lists the stable commit IDs that implemented the fix in each branch; compare these against your distribution’s changelog.
• In a test environment, attempt to reproduce the problematic flow insertion (only for safe, controlled testing). The crash should no longer occur in patched kernels.
• Validate that netlink control of OVS succeeds for ordinary activities and that control-plane services (ovs‑vswitchd, ovsdb‑server) operate normally after the kernel upgrade.

---

Operational hardening: beyond patching​

Because the vector involves the control plane and netlink messages, defenders should adopt a conservative posture for network-device management interfaces:

• Restrict management-plane access: ensure OVS management interfaces are reachable only from management subnets and authenticated systems.
• Least privilege for flow programming: disallow untrusted users from performing flow manipulation tasks; enforce RBAC where possible.
• Network microsegmentation: put OVS controllers and orchestration tools in dedicated management networks not directly reachable by tenants.
• Harden host capabilities: use Linux security frameworks (SELinux, AppArmor), seccomp for management agents, and cgroups to limit what management processes can do.
• Audit and alert on netlink usage: monitor for unusual genl/netlink sends from unexpected processes and alert on attempts to send flow modification messages from non‑admin accounts.

These steps reduce the attack surface for control-plane bugs that could otherwise be weaponized to cause host instability or misconfiguration.

---

Why upstream removal was the right engineering choice​

The kernel community prefers surgical, low‑risk changes to the stable trees for security‑sensitive fixes. When a feature has never functioned correctly in practice, and repairing it safely would require a large rewrite across control‑plane parsing and validation, removal followed by a future, well‑tested re‑implementation is typically safer than attempting a complex patch in stable branches. That approach reduces the chance of regressions, unintended side effects, and long‑tail vulnerabilities introduced by hurried fixes. This pattern of “narrow, defensive fixes or safe removal” appears in many kernel advisories and is supported by the upstream maintainers’ comments. (Operational note: kernel maintainers also remind operators that cherry‑picking single commits into vendor trees is not recommended unless performed by experienced maintainers — prefer vendor-supplied packages that include the stable backports.

---

What administrators should tell stakeholders​

• The vulnerability is a kernel-level validation bug in OVS that caused kernel crashes and incorrect masked NSH behavior; it was assigned CVE‑2025‑40254.
• The vendor response removed the unsupported functionality from stable kernels; patched kernel packages are available in modern stable releases and vendor updates.
• Immediate risk is primarily local denial‑of‑service for hosts that allow flow insertion via OVS control paths. Systems that expose OVS management to untrusted users or tenants should be prioritized for patching.
• Apply vendor/kernel updates during the next maintenance window and restrict management-plane access until patches are deployed.

---

Caveats, uncertainties and what remains unverified​

• Public advisories and trackers document the crash stack and the rationale for removing the feature; they do not suggest in‑the‑wild remote exploitation campaigns using this defect at the time of disclosure. That absence of evidence does not mean the vulnerability has zero risk in complex, multi‑tenant deployments — the practical risk is dictated by who can insert OVS flows on your hosts.
• Some downstream vendor trees or embedded appliance kernels may have backported or reintroduced similar code in ways that differ from upstream; always check your vendor advisory and kernel package changelog for the exact commit IDs rather than assuming a version number alone.
• If you operate a mixed estate where Open vSwitch is present in virtual appliances, container hosts or cloud images, the exposure surface expands beyond bare metal — auditing and patching those images is an essential follow‑up step.

---

Final recommendations (actionable summary)​

• Treat CVE‑2025‑40254 as a patch‑now item for any host that runs Open vSwitch and accepts flow changes from multiple principals (multi‑tenant hosts, NFV stacks, cloud images).
• Update kernels using vendor or distribution packages that reference the upstream stable commit IDs that removed the broken set(nsh(... support.
• While waiting for updates, lock down OVS control-plane access, limit who can program flows, and monitor for kernel oops messages that match the published stack traces.
• Prefer full vendor updates and coordinated rolling reboots over ad hoc cherry‑picks; validate each update in a staging environment before wide rollout.

---

CVE‑2025‑40254 is an instructive reminder that even features intended to add flexibility (masked writes, nested attributes, expressive flow actions) bring complexity to validation code; when validation and memory layout diverge, the results are kernel instability and potential service outages. The upstream decision to remove the never‑working set(nsh(... support and reintroduce it later only after a correct, tested design is the cautious path that reduces regression risk — but only if operators promptly apply vendor updates and harden their control planes in the meantime.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center