CVE-2024-53140 in Linux
Zusammenfassung
von VulDB • 20.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
netlink: Beenden ausstehender Dump-Vorgänge beim Schließen des Sockets
Netlink unterstützt das iterative Dumpen von Daten. Es stellt den Familien (families) die folgenden Operationen zur Verfügung: - start – (optional) startet den Dump-Vorgang - dump – eigentliche Dump-Hilfsfunktion, die so lange aufgerufen wird, bis sie 0 zurückgibt - done – (optional) wird zu .start aufgerufen und kann zur Bereinigung verwendet werden
Der gesamte Vorgang ist asynchron, und die wiederholten Aufrufe von .dump erfolgen nicht in einer engen Schleife, sondern werden als Reaktion auf recvmsg() auf dem Socket ausgelöst.
Dies gibt dem Benutzer die volle Kontrolle über den Dump, bedeutet aber auch, dass der Benutzer den Socket schließen kann, ohne das Ende des Dumps zu erreichen. Um sicherzustellen, dass .start immer mit .done gepaart ist, prüfen wir vor dem Freigeben des Sockets, ob ein Dump-Vorgang noch läuft, und rufen im Falle eines laufenden Dumps .done auf.
Die Komplikation besteht darin, dass Sockets aus dem Bottom-Half-Kontext (BH) freigegeben werden können und .done schlafen darf. Daher verwenden wir eine Workqueue, um den Aufruf bei Bedarf zu verschieben.
Leider funktioniert dies nicht korrekt. Was wir verschieben, ist nicht die Bereinigung, sondern das Freigeben einer Referenz auf den Socket. Wir haben keine Garantie, dass wir die letzte Referenz besitzen; wenn jemand anderes den Socket hält, kann er ihn im BH freigeben, und wir stehen wieder vor dem gleichen Problem.
Der gesamte Mechanismus scheint jedoch unnötig zu sein. Nur der Benutzer kann mit Dumps interagieren, sodass wir beim Schließen des Sockets bereinigen können. Das Schließen erfolgt immer im Prozesskontext. Asynchroner Code kann den Socket zwar nach dem Schließen noch zugreifen, Benachrichtigungs-SKBs (skbs) an ihn senden usw., aber keine Dumps können starten, enden oder anderweitig Fortschritte erzielen.
Löschen Sie die Workqueue und leeren Sie den Dump-Status direkt aus dem Release-Handler. Beachten Sie, dass weitere Bereinigungen in -next möglich sind; beispielsweise rufen wir jetzt immer .done auf, bevor die Hauptmodulreferenz freigegeben wird, sodass der Dump keine eigene Referenz halten muss.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.