CVE-2023-54149 in Linux
Сводка
по VulDB • 18.05.2026
В ядре Linux была устранена следующая уязвимость:
net: dsa: избежать подозрительного использования RCU для синхронизированных MAC-адресов с поддержкой VLAN
При использовании драйвера felix (единственного, который поддерживает фильтрацию UC и MC) в качестве мастера DSA для произвольного другого коммутатора DSA можно наблюдать следующий стек вызовов при присоединении портов нижележащего коммутатора к мосту с поддержкой VLAN:
============================= 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
Суть проблемы заключается в том, что функция vlan_for_each() ожидает контекста rtnl_lock(), но не получает его при вызове из ndo_set_rx_mode() мастера DSA.
Вызывающей функцией здесь является dsa_slave_set_rx_mode() — метод dsa_port_bridge_host_fdb_add() интерфейса DSA-подчиненного устройства, который вызывается из отложенной работы dsa_slave_switchdev_event_work().
Мы приложили значительные усилия, чтобы избежать использования контекста rtnl_lock() в этом пути вызова в коммите 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work"), и вызов rtnl_lock() просто не является вариантом из-за возможности взаимной блокировки (deadlock) при вызове dsa_flush_workqueue() из путей вызовов, которые уже удерживают rtnl_lock() — а это практически все пути.
Таким образом, когда мастер DSA вызывает vlan_for_each() из своего ndo_set_rx_mode(), состояние драйвера 8021q на этом устройстве действительно не защищено от одновременного доступа ничем.
Изучив net/8021q/, я считаю, что vlan_info->vid_list не был специально спроектирован с учетом обхода через RCU, поэтому введение RCU-варианта vlan_for_each() — vlan_for_each_rcu() — будет непростой задачей, и к тому же это не совсем то, что нам нужно.
В целом я полагаю, что решение не должно находиться в net/8021q/; функция vlan_for_each() не предназначена для этой задачи. DSA не требует удержания rtnl_lock() как такового — поскольку мы блокируем не изменение состояния netdev, а лишь одновременные добавления/удаления в списке VLAN. Нам даже не нужен контекст, допускающий сон (sleepable context) — колбэк vlan_for_each() просто планирует отложенную работу.
Предлагаемое решение заключается в устранении зависимости от vlan_for_each() и реализации вручную (open-code) не блокирующей сон альтернативы, не требующей rtnl, на основе копий списка VLAN, модифицированных через .ndo_vlan_rx_add_vid() и .ndo_vlan_rx_kill_vid().
If you want to get best quality of vulnerability data, you may have to visit VulDB.