CVE-2026-23203 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
net: cpsw_new: 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/496 RTNL: assertion failed at net/8021q/vlan_core.c (236) Modules linked in: CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 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/0xd8 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/0x5
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/06/2026
The vulnerability described in CVE-2026-23203 affects the Linux kernel's networking subsystem, specifically within the cpsw_new driver implementation. This issue stems from a conflict between the removal of RTNL (Routing Netfilter Lock) for IPv6 multicast membership operations and the expectation that certain operations within the cpsw_ndo_set_rx_mode callback function require this lock. The problem manifests as a kernel warning and assertion failure when processing multicast group additions on the BeagleBone Black platform, indicating a fundamental inconsistency in lock management between different kernel subsystems. The root cause lies in how the vlan_for_each() function was modified to operate without the RTNL lock, while the cpsw_add_mc_addr() function still expects this lock to be held during its execution.
The technical flaw occurs because the cpsw_ndo_set_rx_mode callback function, which handles multicast address management for the CPSW (Ethernet switch) driver, directly calls vlan_for_each() without proper lock context. This function is invoked from multiple code paths, some with RTNL lock held and others without, creating an inconsistent locking scenario. The kernel's RTNL lock is crucial for maintaining consistency in network configuration operations, particularly when dealing with VLAN operations and multicast group management. When the RTNL lock is not properly held during vlan_for_each() execution, it triggers the assertion failure in net/8021q/vlan_core.c at line 236, demonstrating a classic race condition scenario. This type of vulnerability falls under CWE-362, which describes concurrent execution using shared data structures without proper synchronization mechanisms.
The operational impact of this vulnerability extends beyond simple assertion failures to potentially destabilize the network subsystem and compromise system stability. The warning trace shows that the issue occurs during normal multicast group addition operations initiated by rpcbind, indicating that legitimate network operations can trigger kernel panics or system crashes. This vulnerability affects embedded systems like the BeagleBone Black where network reliability is critical, and the presence of such a flaw could lead to network outages or complete system failures. The kernel's work queue approach provides a mechanism for deferring operations that require specific locking contexts, allowing the system to maintain proper lock ordering while still processing the necessary multicast operations. This vulnerability aligns with ATT&CK technique T1499.001, which involves network denial of service attacks through kernel-level vulnerabilities.
The resolution strategy involves executing the actual processing within a work queue, a pattern previously implemented successfully in the icssg-prueth driver. This approach eliminates the direct dependency on RTNL lock context by deferring the problematic operations to a separate execution context where proper synchronization can be maintained. By moving the multicast address processing to a work queue, the system avoids the immediate lock contention that was causing the assertion failure. The work queue implementation ensures that the vlan_for_each() operations can proceed without requiring the RTNL lock in the immediate context of the ndo_set_rx_mode callback. This mitigation strategy represents a common pattern for handling kernel lock conflicts and demonstrates proper kernel development practices for managing concurrent access to shared resources. The solution follows established kernel design principles for asynchronous processing of operations that cannot be safely executed under certain locking constraints, effectively resolving the deadlock scenario while maintaining the intended functionality of multicast group management.