CVE-2023-54149
Açıklama
Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: net: dsa: senkronize edilmiş VLAN-aware MAC adresleri için şüpheli RCU kullanımından kaçınıldı Rastgele başka bir DSA anahtarı için DSA master olarak felix sürücüsü (UC filtreleme ve MC filtrelemeyi destekleyen tek sürücü) kullanıldığında, downstream anahtar portları VLAN-aware bir köprüye katılırken şu yığın izlemesi görülebilir: ============================= 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 Burada belirtilen durum, vlan_for_each() fonksiyonunun rtnl_lock() bağlamı beklemesidir ancak DSA master'ın ndo_set_rx_mode() fonksiyonundan çağrıldığında bu bağlama ulaşılamamaktadır. Bunu çağıran dsa_slave_set_rx_mode(), ertelenmiş dsa_slave_switchdev_event_work()'dan gelen slave DSA arayüzünün dsa_port_bridge_host_fdb_add() fonksiyonudur. 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work") commit'inde, bu çağrı yolunda rtnl_lock() bağlamından kaçınmak için büyük çaba sarf edilmiştir ve rtnl_lock() tutan çağrı yollarından (temelde hepsinden) dsa_flush_workqueue() çağırırken oluşabilecek deadlock olasılığı nedeniyle rtnl_lock() çağırmak bir seçenek değildir. Bu nedenle, DSA master kendi ndo_set_rx_mode() fonksiyonundan vlan_for_each() fonksiyonunu çağırdığında, bu cihazdaki 8021q sürücüsünün durumu eşzamanlı erişime karşı hiçbir şekilde korunmamaktadır. net/8021q/ incelendiğinde, vlan_info->vid_list yapısının özellikle RCU gezintisi düşünülerek tasarlanmadığı görülmektedir; dolayısıyla vlan_for_each() fonksiyonunun RCU okuma tarafı formu olan vlan_for_each_rcu() tanıtmak kolay olmayacaktır ve zaten tam olarak ihtiyacımız olan şey de bu değildir. Genel olarak çözümün net/8021q/ içinde olmadığına inanıyorum; vlan_for_each() bu görev için uygun değildir. DSA'nın kendiliğinden rtnl_lock() tutulmasına ihtiyacı yoktur - çünkü engellediğimiz şey bir netdev durum değişikliği değil, sadece bir VLAN listesine yapılan eşzamanlı ekleme/çıkarmalardır. Uyutulabilir (sleepable) bir bağlama bile ihtiyacımız yoktur - vlan_for_each() geri çağrımı sadece ertelenmiş iş planlar. Önerilen çözüm yolu, vlan_for_each() bağımlılığını kaldırmak ve .ndo_vlan_rx_add_vid() ile .ndo_vlan_rx_kill_vid() üzerinden değiştirilmiş VLAN listesi kopyalarına dayalı, uyutulamayan ve rtnl gerektirmeyen alternatif bir açık kod yazmaktır.
Nasıl düzeltilir
- Linux Linux3948c69b3837fec2ee5a90fbc911c343199be0ac, 3f9e79f31e51b7d5bf95c617540deb6cf2816a3f, d06f925f13976ab82167c93467c70a337a0a3cda, 6.3 ya da sonraki bir sürüm
Etkilenen ürünler
| Ürün | Etkilenen sürümler | Düzeltildiği sürüm |
|---|---|---|
| Linux Linux | 64fdc5f341db01200e33105265d4b8450122a82e ≤ v < 3948c69b3837fec2ee5a90fbc911c343199be0ac, 64fdc5f341db01200e33105265d4b8450122a82e ≤ v < 3f9e79f31e51b7d5bf95c617540deb6cf2816a3f, 64fdc5f341db01200e33105265d4b8450122a82e ≤ v < d06f925f13976ab82167c93467c70a337a0a3cda, 2daf967a24334865e51520e55190a646dd480cd7, 6.2.10 ≤ v < 6.3, 6.3 | 3948c69b3837fec2ee5a90fbc911c343199be0ac, 3f9e79f31e51b7d5bf95c617540deb6cf2816a3f, d06f925f13976ab82167c93467c70a337a0a3cda, 6.3 |
Sürümünüzü kontrol edin
Ürünü seçin ve kullandığınız sürümü yazın; sürümün etkilenen aralıkta olup olmadığını görün.
Attack Surface Management
Alan adlarınıza bağlı varlıkları, bu varlıklarda çalışan teknolojileri ve bilinen zafiyetleri tek listede görün.