CVE-2026-98497 in Linux
Summary
by MITRE • 10/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified within the Linux kernel's Mellanox ConnectX Ethernet driver, specifically affecting the net/mlx5e subsystem, represents a critical logic error in how Internet Protocol version 6 (IPv6) IPsec policies are translated into hardware flow table entries. This flaw originates from an incorrect mapping of source and destination address masks during the configuration of Flexible Flow Table Entries (FTEs). The core technical issue lies within the mlx5e_ipsec_policy_mask function, which correctly calculates distinct prefix lengths for source and destination addresses based on the XFRM policy definitions. However, when these calculated masks are applied in the setup_fte_addr6 routine, they are erroneously swapped. This means that the mask intended to filter traffic based on the source IPv6 address is incorrectly installed into the hardware field designated for matching destination addresses, while the mask meant for the destination address is placed in the source match field.
This inversion of masks leads to significant operational discrepancies between the software-defined security policy and the actual behavior enforced by the network interface card's hardware offload engine. When an IPv6 XFRM policy specifies different prefix lengths for its source and destination components, the resulting hardware rule becomes fundamentally misaligned with administrative intent. Specifically, the device will attempt to match incoming or outgoing packets against a mask that corresponds to the wrong address type. Consequently, legitimate traffic that should be covered by the IPsec policy may fail to match the hardware rules due to this mismatch, causing it to bypass encryption or authentication checks entirely. Conversely, traffic that falls outside the scope of the intended policy might inadvertently match the swapped masks, leading to incorrect processing such as unnecessary encapsulation or dropping of valid packets.
From a security perspective, this vulnerability undermines the integrity and confidentiality guarantees provided by IPsec. If legitimate traffic is missed by the hardware offload mechanism, it may be processed in software where performance degrades significantly, potentially creating denial-of-service conditions under high load. More critically, if traffic outside the policy scope is incorrectly matched, sensitive data could be subjected to unwanted security processing or dropped entirely, disrupting network connectivity and service availability. In scenarios involving strict access control lists enforced via IPsec policies, this flaw could allow unauthorized communication paths to remain open or block authorized secure channels, effectively breaking the trust model established by the kernel's networking stack.
The remediation for this issue involves correcting the assignment logic within the setup_fte_addr6 function to ensure that each calculated mask is installed into its corresponding and correct address match field in the hardware flow table entry. This alignment restores the fidelity between the software policy definition and the hardware enforcement mechanism, ensuring that source addresses are filtered by source masks and destination addresses by destination masks as originally intended. To mitigate risks associated with similar vulnerabilities in network drivers, organizations should prioritize regular kernel updates and patch management cycles to incorporate fixes for such logic errors. Furthermore, implementing rigorous testing of IPsec configurations across different prefix length combinations can help detect misconfigurations before they impact production environments.
This vulnerability aligns with CWE-841, which describes Improper Enforcement of Mapping Between Logical and Physical Addresses, as the logical policy parameters are not correctly mapped to their physical hardware counterparts. Additionally, it relates to ATT&CK technique T1072, Software Deployment, specifically regarding the installation or configuration of software components that enforce security controls, where a misconfiguration leads to a failure in enforcement mechanisms. By addressing this swap error, the kernel ensures that network traffic is filtered according to the precise parameters defined by system administrators and automated policy engines, maintaining both performance efficiency through hardware offloading and strict adherence to security policies.