EUVD-2026-103737
GHSA-jq4w-vj6x-gwh6
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPosition on network path to mlx5 IPsec host
-
ExploitTarget IPv6 policy with differing src/dst prefixes
-
ExecutionSwapped hardware mask misclassifies traffic
-
ImpactIntercept traffic that bypassed IPsec protection
Vulnerability Assessment
| Exploitation Conditions | Requires a host using an NVIDIA/Mellanox mlx5 (ConnectX) NIC with IPsec hardware offload (XFRM) enabled AND at least one IPv6 XFRM policy whose source and destination prefix lengths differ - only then are the swapped masks installed by setup_fte_addr6(). Policies with equal source/destination prefix lengths are unaffected. Limiting factors that reduce real-world exposure: the specific mlx5 hardware requirement, the non-default IPsec offload configuration, the IPv6-only code path, and the differing-prefix precondition; the flaw is a deterministic rule-installation error, not a remotely injectable payload. |
| Impact | Signals point to a real but narrow, moderate-priority defect rather than a widespread emergency. EPSS is low (0.20%, 9th percentile), there is no CISA KEV listing, and no public exploit is identified - the only external links are the kernel stable fix commits, not exploit code. The vuln.today Decision label is 'this_week', indicating timely but non-emergency remediation. The supplied CVSS of 7.5 (AV:N/AC:H/PR:L/UI:N/C:H/I:H/A:H) rates all three impacts High, which appears generous for the described mechanism: this is a control-plane logic error where mlx5e_ipsec_policy_mask()/setup_fte_addr6() install the IPv6 source and destination prefix masks in the wrong match fields, so the realistic consequence is traffic being matched (or missed) by the wrong IPsec rule - plausibly High confidentiality/integrity if protected traffic is sent in clear, but the uniform C:H/I:H/A:H should be verified against your policy set. Note also that AC:H/PR:L in the supplied vector sits uneasily with the description: the fault is deterministic once an IPv6 XFRM policy with differing source/destination prefix lengths is configured on mlx5 hardware, so the real gating factor is a specialized configuration, not attacker skill or low-privilege network access. Treat the limiting factor (specific hardware + non-default IPsec offload config) as the primary risk reducer. |
| Exploit ScenarioDerived | An operator configures IPv6 IPsec (XFRM) offload on an NVIDIA/Mellanox mlx5 (ConnectX) NIC with a policy whose source and destination prefix lengths differ; because the masks are swapped in hardware, the source match uses the destination prefix and vice versa. As a result, traffic the policy was meant to protect can slip through unencrypted (observable by a network attacker on the path) while unrelated traffic is unexpectedly matched. No public exploit code exists; the condition arises from the deterministic rule-installation bug rather than a crafted attacker payload. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
IPv6 IPsec hardware-offload policy enforcement in the Linux kernel's mlx5e driver installs swapped source and destination prefix masks, so a Mellanox/NVIDIA ConnectX flow-table rule can both fail to cover traffic the XFRM policy is meant to protect and match traffic that falls outside it - a policy-bypass defect in the offload path rather than a memory-safety bug. Only hosts using an mlx5 NIC with IPsec (XFRM) hardware offload enabled and at least one IPv6 policy whose source and destination prefix lengths differ are affected; policies with equal prefix lengths are unaffected. The assessed vector requires privileged access (PR:H) with high attack complexity, EPSS is low at 0.20% (9th percentile), and no public exploit has been identified at time of analysis; patched kernel versions are available and the priority label is this_week.
RemediationAI
Vendor-released patches are available: upgrade to Linux 6.18.55, 7.2.9 or 7.3-rc5, or apply the corresponding stable backports e73f832f0a7b2c6ea45b2124c732d639be97b547, 3803dc8477f08e0dac4050cafee0de43f32727be and 10de7ed8ef4840da9ca21de4c29578657ac367db, which change setup_fte_addr6() to install each mask in its corresponding match field so the offloaded selector again reflects the XFRM policy. Because the defect only manifests when a host uses an mlx5 NIC with IPsec hardware offload and an IPv6 policy whose source and destination prefix lengths differ, environments that cannot update immediately can reduce exposure by aligning the source and destination prefix lengths in their IPv6 XFRM policies or by keeping such policies off the mlx5 offload path; the supplied sources do not describe any other vendor-sanctioned mitigation, and updating remains the complete fix. Review the advisory references at https://nvd.nist.gov/vuln/detail/CVE-2026-98497 and the kernel.org stable commits above for backport confirmation against your distribution kernel before rolling out.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the Linux kernel's net/mlx5e Ethernet driver, which can offload IPsec processing for IPv6 XFRM policies onto Mellanox/NVIDIA ConnectX (mlx5) hardware by programming flow-table entries (FTEs) that encode selector matches for source and destination addresses. mlx5e_ipsec_policy_mask() derives the address masks from the policy's prefix lengths, treating the source and destination lengths independently because IPv6 XFRM policies are allowed to use different prefix lengths on each side. setup_fte_addr6() then writes each computed mask into the address field of the FTE, and it places them in the opposite fields, so the source selector is programmed with the destination prefix length and vice versa. The consequence is a deterministic misprogrammed hardware rule: whenever the two prefix lengths differ, the offloaded selector no longer reflects the policy, producing both false negatives (traffic the policy should cover is not matched and therefore not protected by the offload) and false positives (traffic outside the policy scope is matched). Because the masks are derived from locally configured policy parameters, the trigger is a configuration-and-deployment condition - differing IPv6 source/destination prefix lengths on an mlx5-backed offloaded policy - not an attacker-supplied payload; equal-length prefixes produce identical masks and are therefore benign. No CWE identifier was supplied with the record, and the CPE data maps the issue to the generic linux:linux product family; the kernel commit references (e73f832f0a7b2c6ea45b2124c732d639be97b547, 3803dc8477f08e0dac4050cafee0de43f32727be and 10de7ed8ef4840da9ca21de4c29578657ac367db) are the stable-branch backports of the fix.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Manifests only under a privileged, non-default IPv6 IPsec-offload config with differing prefixes (PR:H, AC:H); protected traffic can be exposed/unprotected (C:H/I:H) with minor drop-related availability (A:L).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix swapped IPv6 IPsec policy masks
IPv6 XFRM policies may use different source and destination prefix lengths. mlx5e_ipsec_policy_mask() builds the corresponding masks independently, but setup_fte_addr6() installs each mask in the opposite address field.
When the prefix lengths differ, this makes the source match use the destination prefix and the destination match use the source prefix. The resulting hardware rule can both miss traffic covered by the policy and match traffic outside it.
Install each mask in its corresponding match field.
Executive ViewAI
A high-severity defect in the Linux kernel's mlx5e network driver can cause IPv6 IPsec offload policies on Mellanox/NVIDIA ConnectX adapters to protect the wrong traffic, potentially leaving intended traffic unprotected or applying encryption to traffic outside policy. Only infrastructure running mlx5 NICs with IPsec hardware offload and asymmetric IPv6 prefix policies is exposed, so impact is concentrated in network segmentation and compliance-sensitive environments rather than general-purpose systems. Leadership should care because silent policy bypass on encrypted links can undermine data-in-transit protections and regulatory obligations, though exploitation requires privileged access and no public exploit has been identified at time of analysis.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB