CVE-2026-98497: net/mlx5e: fix swapped IPv6 IPsec policy masks
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. mlx5eipsecpolicymask() builds the corresponding masks independently, but setupfteaddr6() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel with mlx5e IPsec/XFRM hardware policy offload are affected when an IPv6 XFRM policy has different source and destination prefix lengths. The issue is in the hardware-rule address mask setup.
What conditions are needed for incorrect matching?
An IPv6 IPsec/XFRM policy must use unequal source and destination prefix lengths. Under that condition, the source and destination masks are installed in opposite fields, causing covered traffic to miss the rule or unrelated traffic to match it.
How can I determine whether a policy is at risk?
Review IPv6 XFRM policies used with mlx5e IPsec offload and compare their source and destination prefix lengths. Policies whose prefix lengths differ are the relevant cases.