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:

1. IPSec State Corruption: Security association state may become inconsistent, leading to encryption/decryption failures or policy bypasses
2. Kernel Memory Corruption: The corrupted context data could propagate to other kernel structures through subsequent processing
3. 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:

• Kernel Patch Update 2c6a5be
• Kernel Patch Update 6834d19
• Kernel Patch Update 99aaee9
• Kernel Patch Update 99b3685
• Kernel Patch Update c3db55d

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

# 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