CVE-2023-54149
Unknown Unknown - Not Provided
Use-After-Free in Linux Kernel DSA VLAN Handling Causes RCU Warning

Publication date: 2025-12-24

Last updated on: 2025-12-24

Assigner: kernel.org

Description
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().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-24
Last Modified
2025-12-24
Generated
2026-05-07
AI Q&A
2025-12-24
EPSS Evaluated
2026-05-05
NVD
CVE-2023-54149
EUVD
EUVD-2023-60296
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
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 involves suspicious usage of Read-Copy-Update (RCU) mechanisms in the Linux kernel's Distributed Switch Architecture (DSA) when handling VLAN-aware MAC addresses. Specifically, when using the felix driver as a DSA master with another DSA switch, a stack trace warning about suspicious RCU usage occurs because vlan_for_each() expects rtnl_lock() context, which is not held in this call path. The issue arises because the state of the 8021q driver is not properly protected from concurrent access, leading to potential race conditions. The root cause is that vlan_for_each() is not suitable for this context, and the fix involves removing the dependency on vlan_for_each() and implementing a non-sleepable, rtnl-free alternative to safely handle VLAN list modifications.


How can this vulnerability impact me? :

This vulnerability can lead to race conditions and potential instability in the Linux kernel networking stack when using the felix DSA driver with VLAN-aware bridges. The suspicious RCU usage warning indicates that concurrent access to VLAN data structures is not properly synchronized, which could cause kernel warnings, crashes, or unpredictable network behavior when downstream switch ports join VLAN-aware bridges.


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

This vulnerability can be detected by observing the kernel logs for the specific warning message: 'WARNING: suspicious RCU usage' related to net/8021q/vlan_core.c at line 238. You can check the kernel log using the command: dmesg | grep 'suspicious RCU usage' or journalctl -k | grep 'suspicious RCU usage'. This will help identify if the stack trace related to the felix driver and DSA master VLAN-aware bridge issue is present.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability has been resolved. The fix removes the dependency on vlan_for_each() and replaces it with a non-sleepable, rtnl-free alternative to avoid the suspicious RCU usage. Since calling rtnl_lock() is not an option due to potential deadlocks, applying the patch or upgrading to a fixed kernel version is the recommended step.


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