Das Wichtigste in Kürze
- Im Linux-Kernel steckte seit Juli 2023 ein Fehler, der Schreibzugriffe spurlos verschwinden lassen konnte — ohne Fehlermeldung, ohne Absturz.
- Betroffen sind Kernel ab Linux 6.6, wenn Transparent Hugepages aktiv sind, das Programm MADV_FREE nutzt und der Speicher unter cgroup-Limits knapp wird.
- Der Fehler ist nicht theoretisch: Nutzer der Datenanalyse-Bibliothek Polars verloren damit echte Produktionsdaten.
- Die Korrektur wurde nach Linux 7.3-rc3 aufgenommen, umfasst eine einzige Codezeile und ist für die Stable-Kernel zum Rückportieren markiert.
Hinweis: Dieser Beitrag enthält Affiliate-Links (mit * gekennzeichnet). Kaufst du über einen dieser Links, erhalte ich eine kleine Provision — für dich ändert sich der Preis nicht.
GEFAHR! Der schlimmste Fehlertyp überhaupt
Es gibt Fehler, die dir um die Ohren fliegen: Kernel-Panic, Absturz, rote Meldung im Protokoll. Ärgerlich, aber ehrlich. Und dann gibt es diese Sorte.
Dein Programm schreibt Daten. Es bekommt kein Problem gemeldet. Der Rechner läuft weiter. Nur sind die Daten später einfach nicht da. Genau das konnte im Linux-Kernel seit drei Jahren passieren.
Gemeldet wurde der Fehler Anfang September, zusammen mit einem kleinen C-Programm zum Nachstellen. Das ist der Grund, warum er jetzt so schnell verschwindet.
SO entsteht der Fehler — einfach erklärt
Drei Zutaten müssen zusammenkommen. Keine davon ist exotisch:
1. Transparent Hugepages (THP). Normalerweise verwaltet Linux den Arbeitsspeicher in kleinen Häppchen von vier Kilobyte. Bei THP fasst der Kernel viele davon zu großen Blöcken zusammen — das spart Verwaltungsaufwand und macht speicherhungrige Programme schneller. Bei den meisten Distributionen ist das standardmäßig an.
2. MADV_FREE. Damit sagt ein Programm dem Kernel sinngemäß: „Diesen Speicherbereich brauche ich gerade nicht. Wenn du eng wirst, nimm ihn dir.“ Es ist ein Angebot, keine Freigabe. Schreibt das Programm später wieder hinein, soll der Bereich wieder ihm gehören.
3. Speicherdruck unter cgroup-Limits. cgroups begrenzen, wie viel Arbeitsspeicher eine Gruppe von Prozessen bekommen darf. Genau damit arbeiten Docker, Podman, systemd, Kubernetes und LXC-Container.
Trifft alles zusammen, konnte der Kernel den angebotenen Bereich einkassieren, obwohl schon wieder hineingeschrieben worden war. Das Programm merkte davon nichts — die Schreibvorgänge waren weg.
SCHOCK: Das ist bereits echten Nutzern passiert
Bei solchen Meldungen ist die ehrliche Antwort meistens: theoretisch möglich, praktisch kaum. Hier nicht. Anwender der weit verbreiteten Datenanalyse-Bibliothek Polars berichteten über Datenverlust im Produktivbetrieb, der sich auf genau diesen Kernel-Fehler zurückführen ließ.
Warum trifft es ausgerechnet solche Software? Weil Analyse- und Datenbankbibliotheken riesige Speicherbereiche verwalten, aggressiv wieder freigeben und typischerweise in Containern mit Speicherlimit laufen. Damit sind alle drei Zutaten beisammen.
So sieht die Lage bei dir aus
Ein Homelab mit Proxmox, ein paar Docker-Containern und Nextcloud hat den Fehler vermutlich nie ausgelöst — es braucht echten, dauerhaften Speicherdruck. Wer aber Container mit knappen Speichergrenzen fährt und darin Datenverarbeitung laufen lässt, war im Risikobereich.
Was jetzt hilft:
- Warten und aktualisieren. Die Korrektur ist fürs Rückportieren markiert. Sie landet also in den gepflegten Stable-Kernels und damit in den regulären Updates von Debian, Ubuntu, Fedora und Co. Kernel aktuell halten reicht.
- Kernel-Version prüfen.
uname -rzeigt sie an. Alles ab 6.6 kommt grundsätzlich infrage. - Speicherlimits kontrollieren. Container, die permanent am Limit kratzen, sind ohnehin ein Betriebsproblem — hier waren sie zusätzlich der Auslöser.
- Backups verifizieren. Ein Backup, das nie zurückgespielt wurde, ist eine Behauptung. Genau bei stillen Fehlern zeigt sich, ob die Sicherung wirklich vollständig ist.
Für Windows-Arbeitsplätze und externe Datenträger im Homelab leistet eine Backup-Lösung wie EaseUS Todo Backup Home* dabei gute Dienste — entscheidend bleibt aber der Rückspieltest, nicht die Software.
EXTRA-TIPP: Eine Zeile, drei Jahre
Der Fix umfasst eine geänderte Codezeile. Das ist die eigentliche Lehre dieser Geschichte: Es braucht keinen großen Architekturfehler, um Daten zu verlieren. Es reicht eine Bedingung, die in einem seltenen Zusammenspiel falsch greift — und niemand merkt es, weil nichts abstürzt.
FAZIT: Entwarnung mit Nachhall
Für die meisten Homelabs ist die Sache mit dem nächsten Kernel-Update erledigt. Interessant bleibt sie trotzdem, weil sie zeigt, wie lange sich ein stiller Fehler halten kann, solange ihn niemand reproduzieren kann. Erst das kleine Testprogramm machte aus einem diffusen Verdacht einen Einzeiler-Fix.
Häufige Fragen
Welche Kernel-Versionen sind betroffen?
Der Fehler kam im Juli 2023 in den Kernel und ist seit Linux 6.6 in den Veröffentlichungen enthalten. Die Korrektur wurde nach Linux 7.3-rc3 aufgenommen und ist für die gepflegten Stable-Reihen zum Rückportieren markiert.
Muss ich Transparent Hugepages jetzt abschalten?
Nein. THP abzuschalten kostet bei speicherintensiven Anwendungen Leistung und war nie die eigentliche Ursache. Der saubere Weg ist das Kernel-Update über die Paketverwaltung deiner Distribution.
Wie merke ich, ob ich Daten verloren habe?
Genau das ist das Tückische: gar nicht automatisch. Es gab keine Fehlermeldung. Auffällig wären unerklärlich unvollständige Ergebnisdateien oder Datensätze aus Verarbeitungsläufen unter hohem Speicherdruck.
Sind Proxmox-VMs betroffen?
Die Lücke betrifft Arbeitsspeicherverwaltung im Zusammenspiel mit MADV_FREE und cgroup-Limits. Das trifft eher Container-Arbeitslasten als klassische virtuelle Maschinen. Aktuelle Kernel einzuspielen ist trotzdem der richtige Weg.
Quellen
- Phoronix (Michael Larabel): Linux Patched For Silent User-Space Data Loss Bug That’s Existed Since 2023, 14.09.2026
- Linux-Kernel-Mailingliste, x86/urgent-Merge nach Linux 7.3-rc3