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

CVE-2026-23173 Overview

CVE-2026-23173 is a Null Pointer Dereference vulnerability in the Linux kernel's Mellanox mlx5 Ethernet driver (mlx5e). The flaw exists in the Traffic Control (TC) subsystem when deleting TC steering flows, where the driver incorrectly iterates over all possible ports instead of only the actual device communication (devcom) peers that exist. This results in the driver attempting to access non-existent peer devices, triggering a kernel NULL pointer dereference that causes a system crash.

The vulnerability is triggered during the cleanup of TC flower offload rules when the mlx5e_tc_del_fdb_peers_flow function attempts to delete flows for peers that were never initialized. This occurs in multi-port network configurations using the mlx5 driver with TC flow offloading enabled.

Critical Impact

This vulnerability can cause a kernel panic and system crash when TC flows are deleted on systems with Mellanox ConnectX network adapters, potentially leading to denial of service conditions in production environments.

Affected Products

• Linux Kernel with mlx5 driver (mlx5_core module)
• Systems using Mellanox ConnectX network adapters with TC offload
• Linux kernel versions prior to the security patches

Discovery Timeline

• February 14, 2026 - CVE-2026-23173 published to NVD
• February 18, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23173

Vulnerability Analysis

This vulnerability represents a classic Null Pointer Dereference condition in kernel space. The root cause lies in the mlx5e_tc_del_fdb_peers_flow function within the mlx5 core module, which handles the deletion of forwarding database (FDB) flows for multi-port configurations.

When TC steering flows are being cleaned up—such as during qdisc destruction or when unbinding TC blocks—the driver iterates through peer devices to remove associated flow entries. The vulnerable code path assumes all possible port configurations exist and attempts to access their data structures without proper validation. When a non-existent peer is accessed, the NULL pointer dereference occurs at memory address 0x0000000000000008, indicating an offset access on a NULL base pointer.

The crash dump reveals the failure occurs in supervisor (kernel) mode with a write access attempt, confirming this is a kernel-space crash that can bring down the entire system. The call trace shows the flow originating from userspace via the tc utility, through netlink processing, into the qdisc destruction path, and ultimately into the mlx5 driver's flow deletion routine.

Root Cause

The vulnerability stems from improper iteration logic in the TC flow deletion code. Instead of checking which devcom peers are actually connected and initialized, the code assumes all possible peer ports exist. When the iteration reaches a port index that has no corresponding device, the NULL pointer dereference occurs.

The fix modifies the iteration to only process actual devcom peers that the driver is currently connected to, avoiding any access to non-existent peer structures. This ensures that cleanup operations are limited to devices that were properly initialized during the driver's operational lifetime.

Attack Vector

The vulnerability can be triggered through local access by a user with sufficient privileges to manage network traffic control rules. The attack path involves:

1. A system with Mellanox ConnectX network adapters using the mlx5 driver
2. TC flower offload rules configured on the network interface
3. Deletion or unbinding of TC rules, which can occur through the tc command or network reconfiguration
4. During cleanup, the driver attempts to access non-existent peer devices, causing the NULL dereference

While this requires local access and some level of network configuration privileges, the impact is a complete system crash (kernel panic), making it a significant denial of service vector in production environments.

Detection Methods for CVE-2026-23173

Indicators of Compromise

• Kernel panic messages referencing mlx5e_tc_del_fdb_peers_flow in the call trace
• Kernel oops messages with NULL pointer dereference at address 0x0000000000000008
• System crashes occurring during TC rule deletion or network interface reconfiguration
• Crash dumps showing the mlx5_core module in the failing instruction path

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for NULL pointer dereference messages involving mlx5 driver components
• Implement kernel crash dump analysis to identify mlx5e_tc_del_fdb_peers_flow in stack traces
• Deploy system monitoring to detect unexpected reboots following TC configuration changes
• Use kdump or other crash collection mechanisms to capture diagnostic information when kernel panics occur

Monitoring Recommendations

• Enable kernel log forwarding to centralized SIEM for real-time analysis of driver crash events
• Configure watchdog timers to detect and report system hangs related to driver failures
• Monitor network interface stability on systems with Mellanox adapters and TC offload enabled
• Track frequency of TC rule modifications that may trigger the vulnerable code path

How to Mitigate CVE-2026-23173

Immediate Actions Required

• Apply the latest Linux kernel patches that address this vulnerability
• Review systems with Mellanox ConnectX adapters and TC flower offload configurations
• Consider disabling TC offload temporarily on affected systems until patches are applied
• Limit access to network configuration tools to reduce exposure to local exploitation

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix ensures that the TC flow deletion code only iterates over actual devcom peers that exist, rather than assuming all possible ports are present.

Patches are available through the following kernel commits:

• Kernel Commit 2652e2f1253c
• Kernel Commit 62e1d8920f69
• Kernel Commit f67666938ae6
• Kernel Commit fdf8437016f5

Organizations should update to a kernel version containing these fixes through their distribution's package management system.

Workarounds

• Disable TC hardware offload on Mellanox interfaces using ethtool -K <interface> hw-tc-offload off until patches are applied
• Avoid dynamic TC rule modifications on production systems with the vulnerable kernel versions
• Restrict access to network configuration utilities (tc, ip, netlink) to essential personnel only
• Consider using alternative network filtering methods that do not rely on TC offload until the system is patched

# Disable TC hardware offload as a temporary workaround
ethtool -K eth0 hw-tc-offload off

# Verify the setting has been applied
ethtool -k eth0 | grep hw-tc-offload

# Check current kernel version to determine if patching is required
uname -r