CVE-2026-23175: Linux Kernel Privilege Escalation Flaw

CVE-2026-23175 Overview

A race condition vulnerability has been identified in the Linux kernel's CPSW (Common Platform Ethernet Switch) network driver. The issue arises from improper RTNL (Routing Netlink) lock handling within the cpsw_ndo_set_rx_mode() callback function. Following changes introduced by commit 1767bb2d47b7 which removed the RTNL lock for IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations, the CPSW driver may execute vlan_for_each() without the required RTNL lock held, triggering kernel warnings and potential system instability.

This vulnerability affects systems using the legacy CPSW network driver, particularly embedded devices like the BeagleBone Black board running AM33XX processors. The issue manifests during IPv6 multicast group join operations when VLAN interfaces are configured.

Critical Impact
Systems running the affected Linux kernel versions with CPSW network driver may experience kernel warnings, potential system instability, and possible denial of service conditions during network multicast operations.

Affected Products

Linux kernel with legacy CPSW network driver
AM33XX-based embedded systems (BeagleBone Black and similar)
Systems using VLAN configurations with IPv6 multicast

Discovery Timeline

2026-02-14 - CVE CVE-2026-23175 published to NVD
2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23175

Vulnerability Analysis

The vulnerability stems from a locking inconsistency introduced when the IPv6 multicast code path was modified to no longer hold the RTNL lock for certain operations. The CPSW driver's ndo_set_rx_mode callback invokes vlan_for_each(), which explicitly asserts that the RTNL lock must be held. However, because ndo_set_rx_mode() can now be invoked both with and without the RTNL lock depending on the code path, this assertion fails in certain scenarios.

The call trace captured on affected systems shows the problematic execution flow:

A userspace process (such as rpcbind) calls setsockopt() with IPV6_ADD_MEMBERSHIP
This triggers igmp6_group_added() which calls __dev_mc_add()
The multicast address sync operation invokes cpsw_add_mc_addr()
vlan_for_each() is called without the RTNL lock, triggering the assertion

This is classified as a Race Condition vulnerability since the RTNL lock state depends on the timing and code path of concurrent network operations.

Root Cause

The root cause is the removal of RTNL lock requirements for IPv6 multicast group operations in upstream commit 1767bb2d47b7. While this change improved scalability for multicast operations, it created an inconsistency for drivers like CPSW that rely on VLAN iteration functions which still require the RTNL lock. The ndo_set_rx_mode() callback cannot simply add rtnl_lock() internally because it is also called from contexts where the lock is already held, which would cause deadlock.

Attack Vector

The vulnerability is triggered through local network configuration operations, specifically when joining IPv6 multicast groups on systems with VLAN interfaces configured over CPSW network interfaces.

The attack scenario involves:

A system configured with the legacy CPSW network driver
VLAN interfaces configured over the CPSW interface
A process performing IPv6 multicast group operations (e.g., IPV6_ADD_MEMBERSHIP socket option)
The kernel processes the request through a code path that doesn't hold the RTNL lock
The VLAN iteration assertion fails, causing kernel warnings and potential instability

The fix resolves this by deferring the actual ndo_set_rx_mode processing to a work queue, following the pattern established by the icssg-prueth driver. This ensures the work queue handler can safely acquire the RTNL lock before calling vlan_for_each().

Detection Methods for CVE-2026-23175

Indicators of Compromise

Kernel warning messages containing "RTNL: assertion failed at net/8021q/vlan_core.c"
Stack traces referencing cpsw_add_mc_addr and vlan_for_each functions
System log entries showing warnings during IPv6 multicast group operations
Unexpected network interface behavior on VLAN-configured CPSW interfaces

Detection Strategies

Monitor kernel logs (dmesg, /var/log/kern.log) for RTNL assertion failure warnings
Use kernel tracing tools to detect unexpected vlan_for_each() calls without proper locking
Implement automated log analysis to flag CPSW driver-related kernel warnings
Monitor system stability metrics on AM33XX-based embedded devices

Monitoring Recommendations

Configure log aggregation to capture and alert on kernel RTNL assertion warnings
Implement network stack health monitoring for embedded systems using CPSW driver
Set up alerts for unusual kernel warning patterns in production environments
Review IPv6 multicast operation logs on affected system configurations

How to Mitigate CVE-2026-23175

Immediate Actions Required

Identify systems running Linux kernels with the legacy CPSW network driver
Prioritize patching for systems with VLAN configurations over CPSW interfaces
Consider temporarily disabling IPv6 multicast on affected systems if patching cannot be immediately applied
Monitor system logs for kernel warnings indicating exploitation attempts

Patch Information

The vulnerability has been resolved in the Linux kernel through commits that implement work queue-based processing for the ndo_set_rx_mode callback in the CPSW driver. The fix defers RX mode processing to a work queue, allowing safe acquisition of the RTNL lock.

Available Patches:

Apply the appropriate patch for your kernel version by updating to a patched kernel release or backporting the fix.

Workarounds

Switch to the new CPSW switch driver (am335x-bone DTS changes from commit c477358e66a3) if platform-compatible
Avoid VLAN configurations over CPSW interfaces on unpatched systems
Disable IPv6 multicast functionality temporarily if the risk outweighs operational requirements
Consider network architecture changes to route multicast traffic through alternative interfaces

bash

# Configuration example
# Check for CPSW driver usage on the system
lsmod | grep cpsw

# Monitor for RTNL assertion warnings in real-time
dmesg -w | grep -i "RTNL.*assertion"

# Verify kernel version and check if patches are applied
uname -r
# Compare against patched kernel versions from vendor

# If using device tree, verify driver configuration
ls /sys/class/net/*/device/driver | grep -i cpsw