CVE-2026-99059 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
wireguard: noise: Ablehnung der Verarbeitung von Antwortnachrichten nach einer intermediären Initiierung
Zwei Threads beginnen mit der Verarbeitung derselben Antwortnachricht, die zweimal empfangen wurde. Der erste Thread A läuft. Während er ausgeführt wird, kommt der zweite Thread B teilweise voran, und während dieser langsamen Berechnung oder sogar beim Blockieren auf down_write() schließt Thread A ab, woraufhin auch eine bereits in Warteschlange eingereihte Handshake-Initiierung im Thread C ausgeführt wird, welcher seinerseits dasselbe down_write() verwendet. Die Erstellung der Handshake-Initiierung gelingt und setzt den Zustand wieder auf „waiting-for-response“ (Warten auf Antwort) zurück und ruft up_write() auf; zu diesem Zeitpunkt nimmt Thread B seine Arbeit wieder auf, da er entweder seine Berechnungen abgeschlossen hat oder endlich die Sperre von down_write() erhalten konnte. Thread B kopiert dann den Zustand zurück zum Peer und beginnt eine neue Sitzung unter Verwendung dieses Zustands, der identisch mit dem in Thread A erstellten Sitzungsstatus ist.
Thread A Thread B Thread C
down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write()
Dies scheint in der Praxis im Wesentlichen nicht auf sinnhafte Weise ausnutzbar zu sein, doch wird sichergestellt, dass dies absolut unmöglich ist, indem der ephemere private Schlüssel, der sich im Stack befindet, mit dem neuesten privaten Schlüssel verglichen wird, den der Handshake-Zustand des Peers hat.
If you want to get best quality of vulnerability data, you may have to visit VulDB.