CVE-2026-64522 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA
mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating software state and skipping hardware offload setup.
That path jumps to the common success label before taking the eswitch mode block. After tunnel-mode validation was moved earlier, the common success label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs, this decrements esw->offloads.num_block_mode without a matching increment.
Return directly after installing the acquire SA offload handle, so only the paths that successfully called mlx5_eswitch_block_mode() call the matching unblock.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability resides in the mlx5e network driver within the Linux kernel, specifically affecting the Mellanox ConnectX-5 and newer family of network adapters. This issue manifests as an underflow condition within the eswitch mode blocking mechanism when processing IPsec security associations. The problem occurs during the handling of acquire-flow temporary security associations where the driver allocates software state but skips hardware offload setup. The technical flaw stems from improper control flow management within the mlx5e_xfrm_add_state() function, which creates a discrepancy in the eswitch mode block accounting mechanism.
The vulnerability exploitation pathway begins when the driver processes IPsec acquire SAs through the mlx5e_xfrm_add_state() function. During this process, the code allocates necessary software state structures and deliberately bypasses hardware offload initialization for temporary security associations. However, the code path execution jumps to a common success label before properly handling the eswitch mode block operations. This design flaw emerged after tunnel-mode validation was relocated earlier in the code flow, resulting in the common success label unconditionally invoking mlx5_eswitch_unblock_mode() function. The issue becomes critical because acquire SAs do not undergo the corresponding mlx5_eswitch_block_mode() call that would increment the esw->offloads.num_block_mode counter, creating an imbalance in the reference counting mechanism.
The operational impact of this vulnerability extends to network security and system stability within environments utilizing Mellanox network adapters with IPsec functionality. When the underflow condition occurs, it can lead to incorrect eswitch mode state management that may result in potential denial of service scenarios or compromised network traffic handling. The vulnerability affects systems where IPsec offloading is enabled through the mlx5e driver, particularly in data center and enterprise networking environments that rely on hardware-accelerated security processing. The issue represents a violation of proper resource management principles and can potentially enable attackers to disrupt normal network operations or create unexpected behavior in the network virtualization layer.
This vulnerability aligns with CWE-129 Input Validation and CWE-682 Incorrect Calculation categories, representing improper handling of reference counting mechanisms and incorrect state management within kernel space drivers. The issue demonstrates characteristics consistent with ATT&CK technique T1059 Command and Scripting Interpreter where malicious actors could potentially exploit the unstable eswitch mode state to manipulate network traffic or create persistent access points. Mitigation strategies should focus on ensuring proper code path execution flow, implementing conditional logic that correctly matches block/unblock operations, and maintaining accurate reference counting for shared kernel resources. The fix requires modifying the driver code to return directly after installing the acquire SA offload handle, ensuring that only code paths that successfully call mlx5_eswitch_block_mode() will subsequently execute the matching mlx5_eswitch_unblock_mode() operation, thereby preventing the underflow condition through proper control flow management and resource accounting.