CVE-2026-23440

High · 7.5

CVSS

7.5

EPSS

0.3%

Published

Apr 3, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in Linux network card drivers can cause secure encrypted connections to stop working after handling a very large amount of traffic, interrupting protected communications until the system is fixed.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Theoretical
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Race condition in mlx5e IPSec full offload ESN handling allows duplicate event processing after xfrm lock release/re-acquire; this corrupts esn_msb, programs invalid hardware state, and triggers anti-replay failures that halt all IPSec traffic.

Why it matters to the business

Systems using Mellanox/NVIDIA ConnectX adapters with IPSec hardware offload may experience sudden, complete loss of encrypted network connectivity after processing roughly 2^31 packets, requiring manual intervention or reboot to restore service; high downstream Linux kernel prevalence increases blast radius.

How an attack unfolds

An attacker sends a sustained stream of IPSec packets to force an ESN wrap event from the NIC; the driver validates the event but then calls mlx5_accel_esp_modify_xfrm which drops the lock, allowing a second spurious event to be processed before re-arming; duplicate processing increments esn_msb incorrectly and installs a bad state that permanently breaks anti-replay checks.

How to fix it

Upgrade to a Linux kernel containing the fix that re-arms esn_event_arm immediately after validation; apply the patch series referenced in the commit or later stable releases that include it; disable IPSec full offload on affected mlx5e devices as a temporary workaround if patching is delayed.

How to confirm the fix worked

Confirm the driver source contains the re-arm of esn_event_arm prior to the mlx5_accel_esp_modify_xfrm call; inspect /proc or ethtool statistics for absence of repeated ESN events and verify that IPSec traffic continues without anti-replay drops after large packet volumes.

Typical attack path

Establish or hijack an IPSec SA using hardware offload on an mlx5e interface
Transmit sufficient packets (>2^31) to trigger hardware ESN wrap notification
Exploit the window between event validation and re-arming during mlx5_accel_esp_modify_xfrm
Cause duplicate processing that corrupts esn_msb
Force hardware into invalid ESN state resulting in traffic blackholing

How to detect it

Search kernel logs for repeated mlx5e ESN event processing messages or anti-replay failure indicators around the time of traffic loss; correlate with high-volume IPSec flows on mlx5 interfaces; examine dmesg or journalctl for esn_msb or xfrm state corruption warnings.

What your security team should do

Prioritize kernel updates on all hosts with mlx5e IPSec offload enabled within the next maintenance window
Monitor EPSS trend and re-evaluate if exploit code appears given the +30% rise
Temporarily disable hardware IPSec offload via ethtool or module parameters on high-value systems until patched
Add kernel version and mlx5e IPSec configuration to asset inventory for rapid scoping

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed