PT-2026-30135 · Linux · Linux
Published
2026-04-03
·
Updated
2026-04-03
·
CVE-2026-23440
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux