CVE-2026-23440

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