CVE-2026-23441: Linux Kernel Race Condition Vulnerability

CVE-2026-23441 Overview

A race condition vulnerability has been identified in the Linux kernel's mlx5e network driver, specifically affecting the IPSec ASO (Advanced Security Offload) context handling. The vulnerability exists in how the driver manages concurrent access to a shared DMA-mapped context structure used for IPSec offload operations on Mellanox ConnectX network adapters.

The driver uses a single mlx5e_ipsec_aso struct for each Physical Function (PF), which contains a shared DMA-mapped context for all ASO operations. A race condition occurs because the ASO spinlock is released before the hardware has finished processing the Work Queue Element (WQE). When a second operation is initiated immediately after, it can overwrite the shared context in the DMA area before the first operation completes, leading to data corruption and unexpected behavior.

Critical Impact
Concurrent IPSec offload operations may result in corrupted DMA context data, potentially causing incorrect security processing, system instability, or denial of service conditions in networked environments utilizing hardware IPSec acceleration.

Affected Products

Linux kernel versions with mlx5e driver IPSec offload support
Systems utilizing Mellanox ConnectX network adapters with IPSec hardware acceleration
Linux kernel stable branches prior to the security patches

Discovery Timeline

2026-04-03 - CVE CVE-2026-23441 published to NVD
2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-23441

Vulnerability Analysis

This vulnerability represents a classic Time-of-Check Time-of-Use (TOCTOU) race condition within the kernel's network driver subsystem. The mlx5e_ipsec_aso structure is designed as a singleton per Physical Function to optimize memory usage and reduce overhead for IPSec hardware offload operations. However, this design decision creates a vulnerability when multiple IPSec operations attempt to utilize the shared ASO context concurrently.

The fundamental issue lies in the timing of the spinlock release relative to hardware processing completion. The ASO spinlock protects access to the shared context during software operations, but is released before the hardware has finished processing the associated Work Queue Element. This creates a window where a second operation can acquire the lock and begin modifying the shared DMA context while the hardware is still reading from or writing to that same memory region.

When the first operation's completion handler eventually processes the hardware response, it reads from the now-corrupted context, potentially leading to incorrect IPSec state management, security policy violations, or kernel crashes depending on how the corrupted data is interpreted by subsequent code paths.

Root Cause

The root cause is improper synchronization between software lock management and hardware DMA operations. The shared mlx5e_ipsec_aso context relies on a spinlock for mutual exclusion during software access, but this protection does not extend to cover the full lifecycle of the hardware operation. The DMA area containing the ASO context can be modified by a subsequent operation before the hardware has completed its read, violating the assumption that the context remains stable throughout the hardware processing phase.

Attack Vector

The vulnerability can be triggered through high-frequency IPSec operations that stress the shared ASO context, potentially causing:

IPSec State Corruption: Security association state may become inconsistent, leading to encryption/decryption failures or policy bypasses
Kernel Memory Corruption: The corrupted context data could propagate to other kernel structures through subsequent processing
Denial of Service: System instability or crashes resulting from unexpected hardware behavior when processing corrupted context

The attack requires the ability to generate high-volume IPSec traffic on an affected system with mlx5e hardware offload enabled, typically requiring local access or the ability to send substantial network traffic to the target system.

Detection Methods for CVE-2026-23441

Indicators of Compromise

Unexpected kernel warnings or errors in dmesg related to mlx5e or IPSec subsystems
Sporadic IPSec connection failures or authentication errors under load
Kernel crash dumps indicating corruption in mlx5e_ipsec_aso or related structures
Abnormal network performance degradation during encrypted traffic processing

Detection Strategies

Monitor kernel logs for mlx5e driver warnings or error messages indicating ASO context inconsistencies
Implement system monitoring for unexpected kernel crashes or hangs on systems with Mellanox ConnectX adapters using IPSec offload
Deploy network monitoring to detect unusual IPSec session failures or authentication anomalies
Use kernel debugging tools like ftrace or eBPF to monitor spinlock contention patterns in the mlx5e driver

Monitoring Recommendations

Enable enhanced logging for the mlx5e driver module on affected systems
Configure crash dump collection (kdump) to capture kernel state during any related crashes
Monitor IPSec connection reliability metrics for systems utilizing hardware offload
Implement alerting for unusual patterns in network driver error rates

How to Mitigate CVE-2026-23441

Immediate Actions Required

Update the Linux kernel to a patched version containing the fix for this race condition
If immediate patching is not possible, consider temporarily disabling IPSec hardware offload on affected mlx5e interfaces
Review systems utilizing Mellanox ConnectX adapters with IPSec offload for signs of instability
Prioritize patching for systems handling sensitive encrypted network traffic

Patch Information

Multiple kernel stable branch patches have been released to address this vulnerability:

The fix introduces a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held, ensuring subsequent processing uses this saved per-object context and maintaining data integrity throughout the hardware operation lifecycle.

Workarounds

Disable IPSec hardware offload by configuring the mlx5e driver to use software-only IPSec processing until patching is complete
Reduce concurrent IPSec operation load where feasible to minimize race condition probability
Consider implementing network segmentation to limit IPSec traffic volume on affected systems
Apply kernel live patching (kpatch/livepatch) if available for your distribution to minimize downtime

bash

# Disable IPSec hardware offload on mlx5e interface (temporary workaround)
# Check current offload status
ethtool -k eth0 | grep ipsec

# Disable IPSec crypto offload if supported
ethtool -K eth0 esp-hw-offload off

# Verify the change
ethtool -k eth0 | grep ipsec