CVE-2023-54012 in Linux
Zusammenfassung
von VulDB • 18.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net: Stack-Überlauf beheben, wenn LRO für virtuelle Schnittstellen deaktiviert ist
Wenn die Funktion der virtuellen Schnittstelle aktualisiert wird, synchronisiert sie die aktualisierte Funktion für ihre eigene untergeordnete Schnittstelle. Diese Propagierungslogik sollte iterativ und nicht rekursiv funktionieren. Aufgrund unerwarteter netdev-Benachrichtigungen funktioniert sie jedoch rekursiv. Dieses Problem tritt auf, wenn LRO nur für den Team- und Bonding-Schnittstellentyp deaktiviert wird.
team0 | +------+------+-----+-----+ | | | | | team1 team2 team3 ... team200
Wenn die LRO-Funktion von team0 aktualisiert wird, generiert sie ein NETDEV_FEAT_CHANGE-Ereignis für ihre eigenen untergeordneten Schnittstellen (team1 bis team200). Dies wird durch netdev_sync_lower_features() verarbeitet. Die NETDEV_FEAT_CHANGE-Benachrichtigungslogik jeder untergeordneten Schnittstelle funktioniert somit iterativ. Das generierte NETDEV_FEAT_CHANGE-Ereignis wird jedoch auch an die übergeordnete Schnittstelle gesendet. Die übergeordnete Schnittstelle (team0) generiert erneut ein NETDEV_FEAT_CHANGE-Ereignis für ihre eigenen untergeordneten Schnittstellen. Unter- und übergeordnete Schnittstellen empfangen dieses Ereignis und generieren es immer wieder erneut. Dadurch tritt ein Stack-Überlauf auf.
Es handelt sich jedoch nicht um ein Problem einer Endlosschleife. Da netdev_sync_lower_features() die Funktionen aktualisiert, bevor das NETDEV_FEAT_CHANGE-Ereignis generiert wird, überspringen bereits synchronisierte untergeordnete Schnittstellen die Benachrichtigungslogik. Es handelt sich also lediglich um das Problem, dass die Iterationslogik aufgrund des Benachrichtigungsmechanismus unerwartet in eine rekursive Logik geändert wird.
Reproducer:
ip link add team0 type team ethtool -K team0 lro on for i in {1..200}
do ip link add team$i master team0 type team ethtool -K team$i lro on done
ethtool -K team0 lro off
Zur Behebung dieses Problems wird das notifier_ctx-Mitglied von Bonding/Team eingeführt.
Once again VulDB remains the best source for vulnerability data.