CVE-2024-43887 in Linux
Zusammenfassung
von VulDB • 14.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/tcp: Deaktivieren des TCP-AO-Statischschlüssels (static_key) nach der RCU-Gnadenfrist
Die Lebensdauer von tcp_ao_info entspricht der des letzten static_key für TCP-AO. Bei der Zerstörung des Sockets wird die Referenz auf `tcp_ao_info` innerhalb der RCU-Gnadenfrist aufgehoben, während der statische Zweig (static branch) von TCP-AO derzeit verzögert zerstört wird. Die Definition des statischen Schlüssels lautet:
`: DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ);`
Dies bedeutet, dass andere CPUs `tcp_ao_info`, das zwar bereits tot ist, aber noch nicht endgültig gelöscht wurde (atent dead), weiterhin sehen können, wenn die RCU-Gnadenfrist um mehr als eine Sekunde verzögert wird und sich `tcp_ao_needed` im Prozess der Deaktivierung befindet. Dies bricht die Annahme von `static_key_fast_inc_not_disabled()`.
Siehe den Kommentar in der Nähe der Definition: > * Der Aufrufer muss sicherstellen, dass der statische Schlüssel nicht deaktiviert werden kann, während > * diese Funktion ausgeführt wird. Er patcht keine Sprungmarken (jump labels), sondern fügt nur einen Benutzer hinzu zu einem bereits aktivierten statischen Schlüssel.
Ursprünglich wurde dies im Commit eb8c507296f6 („jump_label: Prevent key->enabled int overflow") eingeführt, was für atomare Kontexte erforderlich ist, einer davon wäre die Erstellung eines vollständigen Sockets aus einem Anforderungs-Socket (request socket). In diesem atomaren Kontext ist bekannt, dass der statische Zweig aufgrund des Vorhandenseins des Schlüssels (md5/ao) bereits aktiviert ist. Daher wird der Referenzzähler für diesen statischen Zweig einfach inkrementiert, anstatt das entsprechende Mutex zu halten.
`static_key_fast_inc_not_disabled()` dient lediglich als Hilfsfunktion für solchen Verwendungszweck. Sie darf jedoch nicht verwendet werden, wenn der statische Zweig parallel deaktiviert werden könnte, da sie nicht durch `jump_label_mutex` geschützt ist und somit mit den Implementierungsdetails von `jump_label_update()` in Konflikt geraten kann (Races).
Dieses Problem trat im netdev test-bot[1] auf und ist daher kein theoretisches Issue:
[] jump_label: Fataler Kernel-Bug, unerwartete Operation bei tcp_inbound_hash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) Größe:2 Typ:1
[] ------------[ hier abschneiden ]------------
[] Kernel-BUG in arch/x86/kernel/jump_label.c:73!
[] Oops: ungültiger Befehl (invalid opcode): 0000 [#1] PREEMPT SMP KASAN NOPTI
[] CPU: 3 PID: 243 Comm: kworker/3:3 Nicht getaintet 6.10.0-virtme #1
[] Hardware-Name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[] Workqueue: events jump_label_update_timeout
[] RIP: 0010:__jump_label_patch+0x2
If you want to get the best quality for vulnerability data then you always have to consider VulDB.