CVE-2026-23175
Unknown Unknown - Not Provided
Race Condition in Linux Kernel CPSW Driver Causing Network Instability

Publication date: 2026-02-14

Last updated on: 2026-04-03

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-14
Last Modified
2026-04-03
Generated
2026-05-27
AI Q&A
2026-02-14
EPSS Evaluated
2026-05-25
NVD
CVE-2026-23175
EUVD
EUVD-2026-5863
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19.0-rc7-next-20260130-yocto-standard
linux_kernel linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's network driver for the cpsw switch. It arises because the function cpsw_ndo_set_rx_mode calls vlan_for_each(), which expects the RTNL lock to be held. However, due to recent changes, the RTNL lock is not always held during these operations, causing an assertion failure and kernel warning.

The root cause is that ndo_set_rx_mode is called both with and without the RTNL lock in different code paths, making it difficult to simply add locking. The solution implemented is to execute the processing in a work queue, deferring execution to avoid the locking issue.


How can this vulnerability impact me? :

This vulnerability can cause kernel warnings and assertion failures, potentially leading to instability or crashes in the network stack on affected devices using the legacy cpsw driver. This could disrupt network functionality and degrade system reliability.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a call trace warning related to the RTNL lock assertion failure in the Linux kernel, specifically involving vlan_for_each() and cpsw_ndo_set_rx_mode().

To detect this issue on your system, you should monitor kernel logs for warnings or call traces similar to the following:

  • Look for kernel warnings mentioning 'RTNL: assertion failed at net/8021q/vlan_core.c (236)' or call traces involving vlan_for_each and cpsw_add_mc_addr.
  • Use the command: dmesg | grep -i 'RTNL: assertion failed' to filter relevant kernel messages.
  • Check for processes triggering the issue, such as rpcbind, as indicated in the trace.

What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by executing the ndo_set_rx_mode callback in a work queue instead of directly, to avoid RTNL lock issues.

Immediate mitigation steps include:

  • Apply the patch or update the Linux kernel to a version that includes the fix where cpsw_ndo_set_rx_mode processing is deferred to a work queue.
  • Avoid manually reverting commits related to the cpsw driver, such as the am335x-bone-common.dtsi changes, which can reintroduce the legacy driver and the issue.
  • Monitor kernel logs for the warning to ensure the issue is resolved after applying updates.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart