CVE-2026-23175: net: cpsw: Execute ndo_set_rx_mode callback in a work queue
In the Linux kernel, the following vulnerability has been resolved:
net: cpsw: Execute ndo_set_rx_mode callback in a work queue
Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for
IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for
IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this
change triggered the following call trace on my BeagleBone Black board:
WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/481
RTNL: assertion failed at net/8021q/vlan_core.c (236)
Modules linked in:
CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT
Hardware name: Generic AM33XX (Flattened Device Tree)
Call trace:
unwind_backtrace from show_stack+0x28/0x2c
show_stack from dump_stack_lvl+0x30/0x38
dump_stack_lvl from __warn+0xb8/0x11c
__warn from warn_slowpath_fmt+0x130/0x194
warn_slowpath_fmt from vlan_for_each+0x120/0x124
vlan_for_each from cpsw_add_mc_addr+0x54/0x98
cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec
__hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88
__dev_mc_add from igmp6_group_added+0x84/0xec
igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0
__ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4
__ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168
do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8
ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c
do_sock_setsockopt from __sys_setsockopt+0x84/0xac
__sys_setsockopt from ret_fast_syscall+0x0/0x54
This trace occurs because vlan_for_each() is called within
cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.
Since modifying vlan_for_each() to operate without the RTNL lock is not
straightforward, and because ndo_set_rx_mode() is invoked both with and
without the RTNL lock across different code paths, simply adding
rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.
To resolve this issue, we opt to execute the actual processing within
a work queue, following the approach used by the icssg-prueth driver.
Please note: To reproduce this issue, I manually reverted the changes to
am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone:
switch to new cpsw switch drv") in order to revert to the legacy cpsw
driver.
Security readout for executives and security teams
Plain-English summary
A Linux locking flaw can occur when IPv6 multicast changes make the legacy CPSW Ethernet driver update receive filters outside the locking context expected by VLAN code. The demonstrated result is a kernel warning. Although the supplied CVSS rates potential confidentiality, integrity, and availability impact as high, exposure appears configuration-dependent.
Executive priority
Treat this as a high-priority inventory and patching issue for embedded or industrial systems using legacy CPSW networking. Fleets without that driver can document non-exposure after verification. Narrow reproduction conditions reduce likely fleet-wide reach, but the 7.0 CVSS score supports timely remediation where the affected configuration exists.
Technical view
The CPSW receive-mode callback can reach vlan_for_each() without the required RTNL lock following an IPv6 multicast locking change. Adding the lock inside the callback is unsafe because callers use different locking contexts. The cited correction moves processing to a work queue. The public description demonstrates an RTNL assertion, but does not establish a practical compromise path.
Likely exposure
Most likely on embedded Linux devices using an affected kernel and the legacy CPSW driver, particularly with VLAN and IPv6 multicast activity. Reproduction required reverting BeagleBone Black device-tree changes to restore the legacy driver. The supplied version metadata should be confirmed against vendor advisories because its exact boundaries are not fully explained.
Exploitation context
The supplied CVSS is 7.0, with local access, high complexity, low privileges, and no user interaction. The CVE is not listed as KEV, and the supplied sources report neither active exploitation nor a public exploit. Observed evidence is limited to a kernel warning and failed locking assertion.
Researcher notes
Reproduction required manually restoring the legacy CPSW driver on a BeagleBone Black. The root cause is a locking-context mismatch introduced after RTNL removal from specified IPv6 multicast membership operations. No CWE is supplied, and the public bundle does not demonstrate how the warning translates into confidentiality, integrity, or availability compromise.
Mitigation direction
Inventory embedded Linux devices for affected kernels and use of the legacy CPSW driver.
Install a vendor-supported kernel containing the applicable cited stable fix.
If updates are unavailable, obtain vendor guidance; the sources provide no separate workaround.
Prioritize review of systems matching the demonstrated BeagleBone Black legacy-driver configuration.
Validation and detection
Confirm each device's kernel and network driver against the CVE record and vendor advisory.
Verify the installed kernel incorporates the applicable cited fix commit.
Review kernel logs for RTNL assertions involving vlan_for_each or cpsw_add_mc_addr.
Regression-test VLAN and IPv6 multicast networking after updating, while monitoring for kernel warnings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23175 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.