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:

A workqueue creation fails (Failed to create a rescuer kthread for wq "mlx5e": -EINTR)
The mlx5e_priv_init function fails with error -12 (ENOMEM - out of memory)
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:

Issuing a devlink command to change eswitch mode to switchdev: devlink dev eswitch set pci/0000:00:03.0 mode switchdev
If this operation fails due to resource constraints (creating the conditions for the vulnerable state)
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:

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

bash

# 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