Kernel Memory Leaks mit kmemleak erkennen und untersuchen

Was kmemleak im Kernel erkennt

Kmemleak unterstützt das Linux Kernel Debugging, indem es nach möglicherweise verwaisten Speicherobjekten sucht. Dazu verfolgt es unterstützte Allokationen und prüft, ob aus gescannten Speicherbereichen Referenzen auf diese Objekte erkennbar sind. Ein nicht als erreichbar erkanntes Objekt erscheint als möglicher Leak, nicht als abschließend bewiesener Fehler.

Stell dir vor, ein Kernel-Modul reserviert ein Objekt und verliert anschließend die letzte Referenz darauf, ohne den Speicher freizugeben. Findet kmemleak bei seiner Referenzsuche keinen Hinweis mehr auf das Objekt, kann es dieses als verdächtig melden. Die Meldung liefert einen Ansatzpunkt, um Allokation und vorgesehenen Lebenszyklus im Code zu untersuchen.

Das Verfahren ähnelt der Erreichbarkeitssuche eines Garbage Collectors, übernimmt aber nicht dessen Bereinigung: Kmemleak gibt gemeldete Objekte nicht frei und repariert keinen Code. Ob ein Objekt tatsächlich verloren ist, muss anhand seiner Nutzung, seiner Besitzverhältnisse und der vorgesehenen Freigabe geklärt werden.

Ein Kernel-Leak betrifft Speicher, den Kernel-Code oder ein Modul verwaltet. Ein Leak in einem PHP-Dienst oder einem anderen User-Space-Prozess ist eine andere Fehlerklasse; kmemleak untersucht nicht dessen Heap. Für die breitere Memory Leak Detection im Hosting-Betrieb kommen deshalb zusätzlich Prozessdaten und andere Diagnosewerkzeuge infrage.

Steigende RAM-Belegung allein beweist weder ein Memory Leak noch dessen Ort. Auch ein veränderter Arbeitsumfang oder länger vorgehaltene Daten können den Bedarf beeinflussen. Ein sinnvoller Ausgangspunkt ist daher ein zeitlich und funktional eingrenzbarer Ablauf, bei dem sich ein Kernel-Verdacht gezielt untersuchen lässt.

Warum Meldungen Verdachtsfälle bleiben

Die Suche nach Zeigerwerten kann nicht jede Bedeutung erkennen, die ein Programm einer Referenz gibt. Liegt eine gültige Referenz außerhalb der gescannten Bereiche oder ist sie so abgelegt, dass kmemleak sie nicht erkennt, kann ein weiterhin benötigtes Objekt als verwaist erscheinen. Das ist ein möglicher Fehlalarm: Die Meldung allein belegt nicht, dass die Freigabe fehlt.

Auch das Gegenteil ist möglich. Ein Zahlenwert kann zufällig wie ein Zeiger in ein Objekt aussehen, obwohl der Code ihn nicht als Referenz verwendet. Kmemleak kann das Objekt dann als erreichbar einstufen und ein tatsächliches Leak übersehen. Eine leere Ausgabe ist deshalb kein Nachweis dafür, dass der untersuchte Code fehlerfrei ist.

Hinzu kommt der Umfang der verfolgten Allokationen: Direkte Page-Allokationen und ioremap werden laut Kernel-Dokumentation nicht verfolgt. Wer einen Speicheranstieg in diesen Bereichen vermutet, kann aus einem unauffälligen kmemleak-Bericht keine Entwarnung für die betreffende Ursache ableiten. Dafür ist eine anders angesetzte Untersuchung nötig.

Die Erreichbarkeit ist somit eine technische Heuristik und keine vollständige semantische Analyse des Programms. Sie beantwortet nicht zuverlässig, ob eine erkannte Referenz sinnvoll genutzt wird oder ob eine übersehene Referenz tatsächlich fehlt. Ein einzelner Fund ist ein Prüfauftrag; fehlende Funde begrenzen lediglich die Aussage des jeweiligen Scans.

Für die Bewertung lohnt es sich, einen Verdacht unter kontrollierten Bedingungen erneut zu erzeugen und anschließend den zugehörigen Codepfad zu betrachten. Insbesondere muss geklärt werden, wer das Objekt besitzt und wann es freigegeben werden sollte. Erst diese Untersuchung kann eine plausible Erklärung für den Befund liefern.

Testumgebung und Voraussetzungen prüfen

Die versionierte Dokumentation für Linux 6.6 dient hier als fachliche Ausgangsbasis. Ob kmemleak auf deinem System tatsächlich verfügbar ist, hängt jedoch vom verwendeten Kernel-Build und seiner Konfiguration ab, nicht allein von der Versionsnummer. Prüfe daher den konkret installierten Distributionskernel und halte Build und Konfiguration für die spätere Auswertung fest.

Eine Voraussetzung ist die einkompilierte Kernel-Option CONFIG_DEBUG_KMEMLEAK. Davon getrennt ist die Laufzeitaktivierung: Ist der Kernel mit CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF konfiguriert, kann der Bootparameter kmemleak=on nötig sein. Plane Änderungen am Bootvorgang ausdrücklich für die freigegebene Testkonfiguration ein.

Für den Zugriff auf die Diagnoseschnittstelle muss außerdem debugfs verfügbar und entsprechend eingebunden sein. Kernel-Konfiguration, Aktivierung und Dateisystemzugriff sind unterschiedliche Prüfpunkte: Eine fehlende Schnittstelle allein verrät noch nicht, welcher davon die Ursache ist. Für den Zugriff können privilegierte Rechte erforderlich sein.

Nutze möglichst eine isolierte VM oder ein dediziertes Testsystem und kläre die Freigabe für Änderungen vorab. Kmemleak verursacht zusätzlichen Aufwand bei Allokationen und Freigaben; die Auswirkung hängt von Umgebung und Last ab. Ohne passende Messungen lässt sich dafür keine allgemeingültige Leistungsstrafe angeben.

Dokumentiere neben dem Kernel auch das untersuchte Modul, den geplanten Ablauf und den Zeitpunkt der Ausgabe. Diagnoseberichte können interne Adressen und weitere sensible Informationen enthalten. Sichere sie zugriffsbeschränkt und prüfe vor einer Weitergabe, welche Angaben für die Fehleranalyse tatsächlich benötigt werden.

Schnittstelle und Diagnosebefehle

Beginne auf dem freigegebenen Testsystem mit einem lesenden Zugriff auf /sys/kernel/debug/kmemleak. Die Datei zeigt aktuell gemeldete Verdachtsfälle. Der Zugriff kann privilegierte Rechte erfordern; eine leere Ausgabe beschreibt nur den sichtbaren Diagnosezustand und belegt nicht, dass der Kernel frei von Speicherlecks ist.

Führe den folgenden Befehl in einer Shell mit ausreichenden Leserechten aus. Er verändert den Diagnosezustand nicht und eignet sich auch, um einen ersten Befund vor weiteren Schritten zu sichern.

cat /sys/kernel/debug/kmemleak

Fehlt die Datei, unterscheide drei mögliche Ursachen: Der Kernel wurde möglicherweise ohne CONFIG_DEBUG_KMEMLEAK gebaut, kmemleak ist zur Laufzeit nicht aktiviert oder debugfs ist nicht am erwarteten Ort eingebunden. Die fehlende Datei allein legt nicht fest, welcher Punkt zutrifft. Prüfe deshalb Build-Konfiguration, Bootkonfiguration und Einbindung getrennt.

Die Tabelle unterscheidet bewusst zwischen Lesen und Schreibzugriffen: Ein Scan und das Bereinigen der sichtbaren Liste verändern den Diagnosezustand. Auch das gegebenenfalls nötige Einhängen von debugfs verändert das System. Führe solche Schritte nur mit Freigabe und den dafür erforderlichen Rechten aus; die Umleitung bei den Schreibbefehlen benötigt ebenfalls ausreichende Rechte.

Verdachtsfälle reproduzierbar eingrenzen

Sichere zunächst die vollständige Ausgabe der Schnittstelle zusammen mit Zeitpunkt, Kernel-Build und Testkonfiguration. Bereits vorhandene Meldungen gehören zum Ausgangsbefund und dürfen nicht ohne Vergleich dem folgenden Test zugeschrieben werden. Bewahre die Ausgabe geschützt auf, da sie interne Adressen und weitere Diagnoseinformationen enthalten kann.

Auf einem freigegebenen Testsystem kannst du anschließend die aktuell sichtbaren Meldungen mit dem folgenden Shell-Befehl aus der Verdachtsliste nehmen. Die Shell benötigt Schreibrechte auf die Schnittstelle. Der Befehl gibt keine Speicherblöcke frei und behebt keine Ursache; ohne vorherige Sicherung können wichtige Hinweise verloren gehen.

echo clear > /sys/kernel/debug/kmemleak

Starte danach einen möglichst eng begrenzten und dokumentierten Ablauf, etwa das Initialisieren und kontrollierte Aufräumen eines zu untersuchenden Moduls. Halte fest, welche Schritte durchgeführt wurden und wann sie abgeschlossen waren. So lässt sich ein späterer Fund konkreter mit dem Ablauf abgleichen, ohne dass die zeitliche Nähe allein schon einen ursächlichen Zusammenhang beweist.

Löse nach dem Ablauf in einer entsprechend berechtigten Shell einen Scan aus und lies anschließend die Schnittstelle erneut. Beide Befehle setzen voraus, dass kmemleak aktiv und die debugfs-Schnittstelle verfügbar ist.

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

Wiederhole den Ablauf kontrolliert und gib ihm ausreichend Zeit. Ein Scan muss nicht sofort einen reproduzierbaren Befund liefern. Vergleiche für eine Regression denselben Test vor und nach der Codeänderung bei möglichst gleicher Kernel-Konfiguration und Last; dokumentiere verbleibende Unterschiede. Ein neuer Verdacht stützt eine Hypothese, ersetzt aber nicht die Prüfung des Objektlebenszyklus.

Modultest und Befundauswertung

Bei einem Modultest kannst du beispielsweise einen Initialisierungspfad ausführen und anschließend den vorgesehenen Aufräumpfad durchlaufen lassen. Taucht danach ein neuer Eintrag auf, notiere zunächst Objektgröße, Alter und Prozesskontext sowie die zugehörigen Testschritte. Diese Angaben helfen, Befunde zuzuordnen; sie zeigen für sich genommen noch nicht, ob das Objekt tatsächlich hätte freigegeben werden müssen.

Der Allokations-Stacktrace führt zur Stelle, an der Speicher angefordert wurde. Von dort aus verfolgst du im Code, wer das Objekt übernimmt und welcher Pfad es wieder freigeben soll. Der Trace muss nicht die Stelle enthalten, an der eine Freigabe unterblieben ist: Allokation und versäumtes Aufräumen können in verschiedenen Funktionen liegen.

Berücksichtige auch die Allokationsreihenfolge: Die Dokumentation beschreibt die Ausgabe in dieser Reihenfolge. Ein früheres verwaistes Objekt kann weitere Meldungen nach sich ziehen. Prüfe deshalb, ob mehrere Einträge zu demselben Objektverbund oder Fehlerpfad gehören, bevor du sie als unabhängige Defekte zählst.

Für eine optionale Funktionsprüfung beschreibt die aktuelle Kernel-Dokumentation das Modul kmemleak-test, das absichtlich Speicherlecks erzeugt. Verwende es ausschließlich in einer isolierten Testumgebung und prüfe vorher, ob es im konkreten Kernel verfügbar und entsprechend konfiguriert ist. Die bewegliche aktuelle Dokumentation garantiert seine Verfügbarkeit nicht für jeden älteren oder distributionsspezifischen Kernel.

Auch bei diesem Diagnosemodul ist eine sofortige Meldung oder ein Treffer beim ersten Scan nicht garantiert. Halte Testzeitpunkt und Scanfolge fest und wiederhole die Untersuchung kontrolliert. Bleibt die Ausgabe zunächst leer, prüfe die Voraussetzungen und den Ablauf, statt daraus allein auf eine funktionierende oder defekte Diagnoseumgebung zu schließen.

Ursache prüfen statt Meldung ausblenden

Beginne bei einem Verdachtsfall mit dem Lebenszyklus des gemeldeten Objekts: Welche Funktion reserviert es, wer übernimmt anschließend die Verantwortung, und wann soll es freigegeben werden? Der Allokations-Stacktrace führt dich zum Ursprung der Reservierung. Ob dort oder an einer späteren Stelle ein Fehler liegt, lässt sich erst anhand des Codepfads beurteilen.

Prüfe besonders die Besitzverhältnisse bei Übergaben zwischen Funktionen und Modulen. Wird eine Referenz weitergereicht, muss klar sein, welche Seite sie behält und welche Seite die Freigabe ausführt. Vergleiche außerdem den regulären Aufräumpfad mit Abbruch- und Fehlerpfaden, etwa wenn eine Initialisierung nur teilweise abgeschlossen wird.

Eine Meldung kann auch entstehen, obwohl eine gültige Referenz existiert, die kmemleak nicht erkennt. Bevor du sie unterdrückst, prüfe daher, wo und in welcher Form der Zeiger gespeichert wird. Dokumentiere, warum das Objekt während seiner vorgesehenen Lebensdauer erreichbar bleibt und auf welchem Weg es schließlich freigegeben wird.

Für geprüfte Sonderfälle stehen Entwicklern Annotationen zur Verfügung: kmemleak_not_leak markiert ein bekanntes Objekt als keinen Leak, lässt es aber weiter auf Referenzen scannen. kmemleak_ignore schließt das Objekt sowohl von der Meldung als auch vom Scan aus. Dadurch können darin enthaltene Referenzen für die Analyse fehlen.

Prüfe die Verfügbarkeit und Semantik der API im tatsächlich verwendeten Kernel; die aktuelle API-Dokumentation ist nicht automatisch eine Zusage für jeden älteren Build. Eine Annotation behebt weder eine fehlende Freigabe noch einen fehlerhaften Besitzwechsel. Setze sie deshalb nicht allein ein, um eine störende Ausgabe verschwinden zu lassen.

Fehlersuche und sicherer Betrieb

Fehlt die Datei /sys/kernel/debug/kmemleak, prüfe zunächst den tatsächlich gestarteten Kernel-Build und dessen Konfiguration. CONFIG_DEBUG_KMEMLEAK muss vorhanden sein; die Versionsnummer einer Distribution allein genügt dafür nicht. Halte Build und Konfiguration fest, damit spätere Vergleiche auf derselben Grundlage stattfinden.

Kontrolliere getrennt davon die Laufzeitaktivierung und die Einbindung von debugfs. Bei CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF kann der Bootparameter kmemleak=on erforderlich sein. Eine fehlende Datei unterscheidet diese möglichen Ursachen nicht selbst; Änderungen am Bootvorgang oder das Einhängen von debugfs gehören in eine freigegebene Testkonfiguration.

Bleibt die Ausgabe nach einem Test leer, prüfe, ob der untersuchte Ablauf tatsächlich ausgeführt wurde und ob zwischen Ablauf und Scan ausreichend Zeit lag. Wiederhole ihn unter dokumentierten Bedingungen und vergleiche mit dem gesicherten Ausgangsbefund. Auch dann bleibt ein leerer Bericht begrenzt: Nicht jede Allokation und nicht jede relevante Referenz wird von kmemleak erfasst.

Sichere vorhandene Befunde vor Änderungen am Diagnosezustand. Die Ausgabe kann interne Adressen und andere sensible Informationen enthalten; behandle sie entsprechend den Zugriffs- und Veröffentlichungsregeln deiner Umgebung. Führe zustandsverändernde Schritte bevorzugt auf einem isolierten, freigegebenen Testsystem aus und berücksichtige den zusätzlichen Diagnoseaufwand, ohne dafür einen unbelegten Prozentwert anzunehmen.

Ein hoher Speicherbedarf oder Memory Pressure ist ein eigenständiges Betriebsproblem und für sich genommen kein Nachweis eines Kernel-Lecks. Für die Einordnung von Wartezeiten und Speicherknappheit hilft der Beitrag zu Memory Pressure im Linux-Kernel. Kombiniere solche Betriebsbeobachtungen mit einer gezielten Code- und Befundprüfung, statt aus einer RAM-Kurve unmittelbar auf die Ursache zu schließen.

Das passende Diagnosewerkzeug wählen

Wähle das Werkzeug nach der vermuteten Fehlerklasse, nicht allein nach dem allgemeinen Symptom steigender Speichernutzung. kmemleak sucht nach möglicherweise verwaisten, unterstützten Kernel-Objekten. Für ungültige Zugriffe oder Speicherprobleme eines Benutzerprozesses ist eine andere Instrumentierung sinnvoll; die Werkzeuge beantworten unterschiedliche Fragen.

Ein Verdacht auf eine verlorene Kernel-Referenz spricht zunächst für kmemleak. Zeigt dagegen ein Fehlerbild auf einen Zugriff außerhalb eines Objekts oder auf bereits freigegebenen Speicher, passt KASAN zur Untersuchung dieser Klasse. KFENCE verfolgt ebenfalls bestimmte Speicherfehler, setzt aber einen anderen Instrumentierungsansatz ein; Verfügbarkeit und Eignung hängen vom konkreten Kernel und der Testumgebung ab.

Liegt der Verdacht bei einem User-Space-Prozess, untersuche dessen Speicher mit einem dafür vorgesehenen Werkzeug wie Valgrind Memcheck. Ein kmemleak-Bericht über Kernel-Objekte ersetzt keine Analyse des Heaps einer Anwendung. Umgekehrt erklärt ein Hinweis aus einem Benutzerprozess nicht automatisch, ob ein Kernel-Modul Speicher verliert.

Für die weitere Arbeit wähle einen reproduzierbaren Test und halte Kernel-Build, Konfiguration und Ablauf fest. Untersuche den gemeldeten Objektlebenszyklus im Code, korrigiere eine nachgewiesene Ursache und wiederhole denselben Ablauf unter möglichst gleichen Bedingungen. Vergleiche die Befunde erneut; das Ausbleiben einer Meldung allein beweist noch keine vollständige Fehlerfreiheit.