CVE-2023-54149 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses
When using the felix driver (the only one which supports UC filtering and MC filtering) as a DSA master for a random other DSA switch, one can see the following stack trace when the downstream switch ports join a VLAN-aware bridge:
============================= WARNING: suspicious RCU usage ----------------------------- net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!
stack backtrace: Workqueue: dsa_ordered dsa_slave_switchdev_event_work Call trace: lockdep_rcu_suspicious+0x170/0x210 vlan_for_each+0x8c/0x188 dsa_slave_sync_uc+0x128/0x178 __hw_addr_sync_dev+0x138/0x158 dsa_slave_set_rx_mode+0x58/0x70 __dev_set_rx_mode+0x88/0xa8 dev_uc_add+0x74/0xa0 dsa_port_bridge_host_fdb_add+0xec/0x180 dsa_slave_switchdev_event_work+0x7c/0x1c8 process_one_work+0x290/0x568
What it's saying is that vlan_for_each() expects rtnl_lock() context and it's not getting it, when it's called from the DSA master's ndo_set_rx_mode().
The caller of that - dsa_slave_set_rx_mode() - is the slave DSA interface's dsa_port_bridge_host_fdb_add() which comes from the deferred dsa_slave_switchdev_event_work().
We went to great lengths to avoid the rtnl_lock() context in that call path in commit 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply not an option due to the possibility of deadlocking when calling dsa_flush_workqueue() from the call paths that do hold rtnl_lock() - basically all of them.
So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(), the state of the 8021q driver on this device is really not protected from concurrent access by anything.
Looking at net/8021q/, I don't think that vlan_info->vid_list was particularly designed with RCU traversal in mind, so introducing an RCU read-side form of vlan_for_each() - vlan_for_each_rcu() - won't be so easy, and it also wouldn't be exactly what we need anyway.
In general I believe that the solution isn't in net/8021q/ anyway; vlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock() to be held per se - since it's not a netdev state change that we're blocking, but rather, just concurrent additions/removals to a VLAN list. We don't even need sleepable context - the callback of vlan_for_each() just schedules deferred work.
The proposed escape is to remove the dependency on vlan_for_each() and to open-code a non-sleepable, rtnl-free alternative to that, based on copies of the VLAN list modified from .ndo_vlan_rx_add_vid() and .ndo_vlan_rx_kill_vid().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability CVE-2023-54149 represents a critical race condition in the Linux kernel's Data Switch Architecture (DSA) subsystem that arises from improper RCU (Read-Copy-Update) usage during VLAN-aware MAC address synchronization. This issue manifests when a DSA master interface operates with the felix driver, which supports unicast and multicast filtering, in conjunction with other DSA switches within a VLAN-aware bridge environment. The problem occurs during the process of downstream switch ports joining a VLAN-aware bridge, triggering a stack trace that indicates suspicious RCU usage in the vlan_core.c file at line 238, specifically with the rcu_dereference_protected() function call. The root cause stems from the vlan_for_each() macro being invoked without proper locking context, as it expects rtnl_lock() but receives none during the DSA master's ndo_set_rx_mode() execution path.
The operational impact of this vulnerability is significant within network infrastructure deployments relying on DSA for switching operations. When the DSA master interface processes VLAN-aware MAC address synchronization through the dsa_slave_switchdev_event_work workqueue, it inadvertently bypasses proper synchronization mechanisms that should protect concurrent access to VLAN data structures. The call stack reveals that the issue originates from dsa_slave_switchdev_event_work which calls dsa_slave_set_rx_mode(), leading to dsa_slave_sync_uc(), and ultimately triggering __hw_addr_sync_dev() that invokes dev_uc_add(), eventually reaching dsa_port_bridge_host_fdb_add(). This sequence demonstrates how the DSA subsystem attempts to avoid rtnl_lock() contention by removing it from critical paths, yet inadvertently creates a scenario where the 8021q driver's VLAN list management becomes unprotected from concurrent modifications. The vulnerability directly relates to CWE-362, which describes a race condition in concurrent programming, and aligns with ATT&CK technique T1059.003 for execution through kernel modules, potentially allowing for privilege escalation or denial of service attacks.
The proposed solution addresses the fundamental architectural mismatch between the DSA subsystem's locking requirements and the 8021q driver's VLAN list traversal mechanisms. Rather than attempting to retrofit RCU support into existing vlan_for_each() implementations, the fix involves creating a custom, non-sleepable alternative that operates without requiring rtnl_lock() or sleeping context. This approach eliminates the dependency on the problematic vlan_for_each() macro by implementing direct access to VLAN list modifications through copies that are synchronized with the .ndo_vlan_rx_add_vid() and .ndo_vlan_rx_kill_vid() callback functions. The solution specifically targets the synchronization mechanism between DSA master and slave interfaces, ensuring that VLAN list operations maintain consistency without introducing the risk of deadlocks or race conditions that could compromise system stability. This remediation approach aligns with security best practices for kernel subsystems where lock-free operations are preferred to maintain system responsiveness while ensuring data integrity, particularly in high-performance network switching environments where such vulnerabilities could lead to complete network service disruption.