CVE-2024-26837 in Linux
Zusammenfassung
von VulDB • 31.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net: bridge: switchdev: Überspringen von MDB-Replays für verzögerte Ereignisse im Offload-Betrieb
Vor dieser Änderung konnte es zu einer Race Condition zwischen der Generierung der Liste der wiederzugeben (zu replizierenden) MDB-Ereignisse und der Erstellung neuer Gruppenmitgliedschaften kommen, entweder durch die IGMP/MLD-Snooping-Logik oder durch Benutzerkonfiguration.
Während neue Mitgliedschaften für Walker von `br->mdb_list` sofort sichtbar sind, wird die Benachrichtigung ihrer Existenz an switchdev-Ereignis-Abonnenten auf einen späteren Zeitpunkt verschoben. Wenn daher eine Replay-Liste während eines Zeitraums generiert wurde, der mit einem solchen Fenster überschneidet, würde sie auch eine Wiederholung des noch nicht zugestellten Ereignisses enthalten.
Der Treiber würde somit zwei Kopien dessen erhalten, was die Bridge intern als ein einzelnes Ereignis betrachtete. Beim Zerstören der Bridge wurde daher nur ein einzelnes Löschereignis für die Mitgliedschaft gesendet. Als Folge davon würden Treiber, die Mitgliedschaften referenzieren (zumindest DSA), bei der Zerstörung der Bridge mit verwaisten Gruppen in ihrer Hardware-Datenbank zurückbleiben.
Dies ist nur ein Problem beim Wiederholen von Hinzufügungen. Während Löschereignisse noch in der Warteschlange für verzögerte Ereignisse stehen können, wurden sie bereits aus `br->mdb_list` entfernt, sodass in diesem Szenario keine Duplikate erzeugt werden können.
Für einen Benutzer bedeutete dies, dass alte Gruppenmitgliedschaften aus einer Bridge, an der zuvor ein Port angehängt war, wieder aktiviert (in der Hardware) werden konnten, wenn der Port einer neuen Bridge beitrat, ohne dass dies der neuen Bridge bekannt war.
Zum Beispiel auf einem mv88e6xxx-System: Erstellen Sie eine Snooping-Bridge und fügen Sie ihr sofort einen Port hinzu:
root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0
Und zerstören Sie dann die Bridge:
root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 . . . . . . . . . .
Die beiden ersten Einträge sind die IPv6-Gruppen, die von der Bridge gesendet wurden.
Fügen Sie dann denselben Port (oder einen anderen Port, der zur selben Hardware-Domäne gehört) einer neuen Bridge hinzu, diesmal mit deaktiviertem Snooping:
root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1
Sollte nun nach der Richtlinie von br1 alles Multicast, einschließlich der beiden IPv6-Gruppen von br0, geflutet werden. Stattdessen sind die alten Mitgliedschaften weiterhin in der Hardware-Datenbank aktiv, was dazu führt, dass der Switch den Verkehr nur zu diesen Gruppen an die CPU (Port 0) weiterleitet.
Beseitigen Sie die Race Condition in zwei Schritten:
1. Sperren Sie die Schreibsperre der MDB, während Sie die Replay-Liste generieren.
Dies verhindert, dass neue Mitgliedschaften während der Generierung der Replay-Liste auftauchen. Es lässt jedoch das Szenario zu, in dem ein verzögertes Ereignis bereits generiert, aber noch nicht zugestellt wurde, bevor die Sperre erworben wurde. Daher:
2. Stellen Sie sicher, dass keine verzögerte Version eines Replay-Ereignisses bereits in der switchdev-Warteschlange für verzögerte Ereignisse eingereiht ist, bevor sie zur Replay-Liste hinzugefügt wird, beim Wiederholen von Hinzufügungen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.