CVE-2026-23203

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue<br /> <br /> Commit 1767bb2d47b7 ("ipv6: mcast: Don&amp;#39;t hold RTNL for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this<br /> change triggered the following call trace on my BeagleBone Black board:<br /> WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: assertion failed at net/8021q/vlan_core.c (236)<br /> Modules linked in:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Hardware name: Generic AM33XX (Flattened Device Tree)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x28/0x2c<br /> show_stack from dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl from __warn+0xb8/0x11c<br /> __warn from warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt from vlan_for_each+0x120/0x124<br /> vlan_for_each from cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88<br /> __dev_mc_add from igmp6_group_added+0x84/0xec<br /> igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt from __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt from ret_fast_syscall+0x0/0x5<br /> <br /> This trace occurs because vlan_for_each() is called within<br /> cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.<br /> Since modifying vlan_for_each() to operate without the RTNL lock is not<br /> straightforward, and because ndo_set_rx_mode() is invoked both with and<br /> without the RTNL lock across different code paths, simply adding<br /> rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.<br /> <br /> To resolve this issue, we opt to execute the actual processing within<br /> a work queue, following the approach used by the icssg-prueth driver.