KernelScan.io

HIGH

mlx5e IPSec ESN Race

CVE-2026-23440

CVSS 7.5 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

KernelScan AI7.5HIGH

01

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix race condition during IPSec ESN update In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1. A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock. So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished. Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic. Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.

02

Engine v0.2.0

Risk summary

This race condition can cause IPSec traffic to completely halt due to anti-replay failures. When the ESN high-order bits are incorrectly incremented due to duplicate event processing, the hardware receives invalid ESN state information, leading to a denial of service condition for IPSec connections.

Affecteddrivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_offload.c

Vulnerability analysis

Root Cause: A race condition exists in the MLX5 IPSec ESN (Extended Sequence Number) event handling path. After validating an ESN wrap event by checking that esn_event_arm is 0x0, the driver calls mlx5_accel_esp_modify_xfrm() which temporarily releases and re-acquires the xfrm state lock. During this window, the hardware can send duplicate events, causing the same ESN update to be processed multiple times.

Attack Surface: This vulnerability affects systems using MLX5 network cards with IPSec hardware offload enabled. The race condition is triggered by hardware ESN wrap events during high-volume IPSec traffic processing. No special privileges are required as this is a hardware-driver interaction issue.

Fix Mechanism: The fix reorders the operations to re-arm the ESN event (set esn_event_arm to 0x1) immediately after validation and before calling mlx5_accel_esp_modify_xfrm(). This prevents duplicate event processing by acknowledging the event before releasing the lock. The mlx5_accel_esp_modify_xfrm() call is moved outside the spinlock context to avoid sleeping while holding the lock.

03

BranchFixed inPatch commit
6.126.12.782051c709dce9
6.186.18.2096c9c25b7468
6.196.19.108d625c15471f
6.66.6.1303dffc083292e
mainline7.0beb6e2e5976a