CVE-2026-23035: Linux Kernel Use-After-Free Vulnerability

CVE-2026-23035 Overview

A null pointer dereference vulnerability has been identified in the Linux kernel's Mellanox mlx5e network driver. The vulnerability exists in the mlx5e_destroy_netdev function which incorrectly accepts an mlx5e_priv structure that can be invalidated (memset to 0) when profile attachment fails. This creates a condition where subsequent operations attempt to access invalid memory, leading to a kernel oops.

The issue specifically manifests when switching the eswitch to switchdev mode fails due to a profile change failure. A subsequent device reload operation triggers a null pointer dereference in the mlx5e_dcbnl_dscp_app function, causing a kernel panic.

Critical Impact

Local attackers with device management privileges can trigger a kernel panic through the devlink interface, causing complete system denial of service and requiring a hard reboot to recover.

Affected Products

• Linux Kernel (mlx5e driver component)
• Systems with Mellanox ConnectX network adapters
• Linux kernel versions prior to the security patches

Discovery Timeline

• 2026-01-31 - CVE CVE-2026-23035 published to NVD
• 2026-02-03 - Last updated in NVD database

Technical Details for CVE-2026-23035

Vulnerability Analysis

The vulnerability occurs in the mlx5e network driver's device lifecycle management. The mlx5e_priv structure is a critical data structure that holds the driver's private state information. When the profile attachment process fails during an eswitch mode change, the kernel issues a memset(0) on this structure, effectively zeroing out all its contents.

The root cause is that the mlx5e_destroy_netdev() function accepts the mlx5e_priv pointer directly rather than the stable netdev structure. When a profile change fails and the rollback also fails (as shown in the error logs with -12 return codes indicating memory allocation failures), the mlx5e_priv structure becomes invalid. However, subsequent cleanup operations still attempt to use this zeroed structure.

The kernel oops occurs at instruction pointer mlx5e_dcbnl_dscp_app+0x23/0x100 when attempting to access memory at address 0x0000000000000370, which corresponds to an offset within the zeroed mlx5e_priv structure.

Root Cause

The vulnerability stems from improper handling of the mlx5e_priv structure during error conditions in the profile change workflow. The mlx5e_priv structure becomes unstable and can be memset to zero when:

1. A workqueue creation fails (Failed to create a rescuer kthread for wq "mlx5e": -EINTR)
2. The mlx5e_priv_init function fails with error -12 (ENOMEM - out of memory)
3. Both the new profile initialization and rollback to the original profile fail

Without proper validation of the priv->profile pointer before cleanup operations, the driver attempts to access invalid memory locations, triggering the null pointer dereference.

Attack Vector

The vulnerability can be triggered through the devlink interface by a local user with appropriate privileges (typically root or CAP_NET_ADMIN capability). The attack sequence involves:

1. Issuing a devlink command to change eswitch mode to switchdev: devlink dev eswitch set pci/0000:00:03.0 mode switchdev
2. If this operation fails due to resource constraints (creating the conditions for the vulnerable state)
3. Subsequently issuing a devlink reload command: devlink dev reload pci/0000:00:03.0

The reload operation triggers the mlx5e_remove() function which calls into the cleanup path without checking if the profile pointer is valid. This results in the null pointer dereference at mlx5e_dcbnl_dscp_app+0x23/0x100.

The attack requires local access and elevated privileges, but in containerized or multi-tenant environments where users may have access to network device management, this could be exploited for denial of service.

Detection Methods for CVE-2026-23035

Indicators of Compromise

• Kernel oops messages containing mlx5e_dcbnl_dscp_app in the call trace
• System logs showing BUG: kernel NULL pointer dereference, address: 0000000000000370
• dmesg entries with mlx5e_priv_init failed or mlx5e_netdev_change_profile: failed to rollback
• Unexpected system reboots following devlink operations on Mellanox adapters

Detection Strategies

• Monitor kernel logs for null pointer dereference exceptions in the mlx5 driver namespace
• Implement audit rules for devlink commands targeting Mellanox network devices
• Track failed eswitch mode changes followed by reload operations
• Deploy kernel crash dump analysis for post-incident forensics

Monitoring Recommendations

• Enable kernel log monitoring with alerts for mlx5e driver errors and kernel oops
• Audit all devlink interface operations in security-sensitive environments
• Monitor system stability metrics following network driver configuration changes
• Implement resource monitoring to detect low memory conditions that could trigger the failure path

How to Mitigate CVE-2026-23035

Immediate Actions Required

• Apply the kernel patches from the official git repositories as soon as possible
• Restrict devlink interface access to trusted administrators only
• Monitor for unusual devlink activity on systems with Mellanox adapters
• Consider disabling eswitch mode changes in production environments until patched

Patch Information

The Linux kernel maintainers have released patches that address this vulnerability by modifying mlx5e_destroy_netdev() to accept the netdev structure directly instead of the priv pointer, ensuring it always operates on a valid network device. Additionally, the mlx5e_remove() function now validates priv->profile before attempting to clean up resources.

Official patch commits are available:

• Kernel Git Commit 4ef8512e
• Kernel Git Commit 66a25f6b
• Kernel Git Commit a7625bac

Workarounds

• Restrict access to the devlink interface using appropriate permissions and capabilities
• Avoid performing eswitch mode changes on production systems under memory pressure
• Implement resource limits to prevent memory exhaustion scenarios that trigger the failure path
• Use kernel live patching solutions where available to deploy fixes without reboot

# Configuration example
# Restrict devlink access to root only and audit commands
# Add to /etc/security/limits.conf to restrict memory for network operations
# Monitor system for devlink commands
auditctl -w /usr/sbin/devlink -p x -k mlx5_devlink_audit

# Check current eswitch mode without modifying
devlink dev eswitch show pci/0000:00:03.0

# Verify kernel version includes the fix
uname -r