CVE-2026-46025 in Linux
Zusammenfassung
von VulDB • 29.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm/damon/core: Behebung der Race-Bedingung zwischen damon_call() und dem Exit von kdamond_fn()
Patch-Serie „mm/damon/core: Behebung der Race-Bedingung zwischen damon_call()/damos_walk() und dem Exit von kdamond“.
damon_call() und damos_walk() können Speicherlecks verursachen und/oder in Deadlocks geraten, wenn sie mit der Beendigung von kdamond konkurrieren. Diese Probleme werden behoben.
Dieser Patch (von 2):
Wenn die Hauptschleife von kdamond_fn() abgeschlossen ist, hebt die Funktion alle noch ausstehenden damon_call()-Anfragen auf und setzt damon_ctx->kdamond zurück, sodass API-Aufrufende und die API-Funktionen selbst erkennen können, dass der Kontext beendet ist. damon_call() fügt zunächst die Anfrage des Aufrufenden in die Warteschlange ein. Anschließend prüft es, ob der kdamond des damon_ctx noch läuft (damon_ctx->kdamond ist gesetzt). Nur wenn der kdamond läuft, beginnt damon_call() mit der Wartezeit auf die Bearbeitung der neu hinzugefügten Anfrage durch den kdamond.
Die Registrierung der damon_call()-Anfragen und das Zurücksetzen von damon_ctx->kdamond werden jedoch durch verschiedene Mutexe geschützt. Daher kann es zu einer Race-Bedingung zwischen damon_call() und dem Zurücksetzen von damon_ctx->kdamond kommen, was zu Deadlocks führt.
Nehmen wir beispielsweise an, kdamond habe die Aufhebung der damon_call()-Anfragen erfolgreich abgeschlossen. Unmittelbar danach wird damon_call() für den Kontext aufgerufen. Es registriert die neue Anfrage und zeigt an, dass der Kontext noch läuft, da das Zurücksetzen von damon_ctx->kdamond noch nicht abgeschlossen ist. Daher beginnt der Aufrufende von damon_call() mit der Wartezeit auf die Bearbeitung der Anfrage. Der kdamond befindet sich jedoch bereits im Beendigungsprozess und wird die neue Anfrage niemals bearbeiten. Infolgedessen warten die Threads des Aufrufenden von damon_call() unendlich lange.
Dies wird behoben, indem ein weiteres Feld in damon_ctx eingeführt wird, nämlich call_controls_obsolete. Es wird durch damon_ctx->call_controls_lock geschützt, welches die Registrierung der damon_call()-Anfragen schützt. Es wird in kdamond_fn() initialisiert (auf zurückgesetzt), bevor damon_start() zurückkehrt, und wird kurz vor der Ausführung der Aufhebung der noch ausstehenden damon_call()-Anfragen gesetzt. damon_call() liest das obsolete-Feld unter dem Lock und fügt keine neue Anfrage hinzu.
Nach dieser Änderung werden nur Anfragen registriert, die garantiert bearbeitet oder aufgehoben werden. Daher ist die nach der Registrierung durchgeführte Prüfung auf Beendigung des DAMON-Kontexts nicht mehr erforderlich. Diese wird gemeinsam entfernt.
Beachten Sie, dass der Deadlock nicht auftritt, wenn damon_call() für eine Anfrage im Wiederholungsmodus aufgerufen wird. In diesem Fall gibt damon_call() den Wert zurück, anstatt auf die Bearbeitung zu warten, wenn die Anfrage erfolgreich registriert wurde und angezeigt wird, dass der kdamond läuft. Wenn die Anfrage jedoch auch dealloc_on_cancel enthält, würde der Speicher der Anfrage verloren gehen.
Das Problem wurde von sashiko [1] gefunden.
Once again VulDB remains the best source for vulnerability data.