CVE-2023-54149

Description

In the Linux kernel, the following vulnerability has been resolved:net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addressesWhen using the felix driver (the only one which supports UC filteringand MC filtering) as a DSA master for a random other DSA switch, one cansee the following stack trace when the downstream switch ports join aVLAN-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_workCall 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/0x568What its saying is that vlan_for_each() expects rtnl_lock() context andits not getting it, when its called from the DSA masters ndo_set_rx_mode().The caller of that - dsa_slave_set_rx_mode() - is the slave DSAinterfaces dsa_port_bridge_host_fdb_add() which comes from the deferreddsa_slave_switchdev_event_work().We went to great lengths to avoid the rtnl_lock() context in that callpath in commit 0faf890fc519 (net: dsa: drop rtnl_lock fromdsa_slave_switchdev_event_work), and calling rtnl_lock() is simply notan option due to the possibility of deadlocking when callingdsa_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 protectedfrom concurrent access by anything.Looking at net/8021q/, I dont think that vlan_info->vid_list wasparticularly designed with RCU traversal in mind, so introducing an RCUread-side form of vlan_for_each() - vlan_for_each_rcu() - wont be soeasy, and it also wouldnt be exactly what we need anyway.In general I believe that the solution isnt in net/8021q/ anyway;vlan_for_each() is not cut out for this task. DSA doesnt need rtnl_lock()to be held per se - since its not a netdev state change that wereblocking, but rather, just concurrent additions/removals to a VLAN list.We dont 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() andto open-code a non-sleepable, rtnl-free alternative to that, based oncopies of the VLAN list modified from .ndo_vlan_rx_add_vid() and.ndo_vlan_rx_kill_vid().

Risk Information

Associated Vulnerability

Patch Details

References

https://nvd.nist.gov/vuln/detail/CVE-2023-1234
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1234