Datenkorruption: 16 Jahre alter SQLite-Bug stört Tailscale über Monate
Der Netzwerkdiensteanbieter Tailscale hat nach der monatelangen Untersuchung eines Fehlers in der SQLite-Datenbank einen 16 Jahre alten Programmierfehler gefunden. Wie das Unternehmen in einem Blogbeitrag schreibt(öffnet im neuen Fenster), führte der Fehler unter spezifischen Bedingungen zur Datenkorruption.
Die unerwarteten Ausfälle begannen im Jahr 2025 und beeinträchtigten die Netzwerkstabilität bei Tailscale über Monate hinweg erheblich. SQLite war bereits seit dem Jahr 2022 als primäre Datenbank im Einsatz und galt als bewährt und zuverlässig.
Im August 2025 meldete die S3-Back-up-Pipeline erste Datenbankbeschädigungen, die sich in den folgenden sechs Monaten auf insgesamt 19 Fälle summierten. Die Suche nach der Ursache gestaltete sich besonders schwierig, da keine Änderungen am Code vorgenommen worden waren und sich der Fehler nicht künstlich reproduzieren ließ.
Schreibtransaktion zu kritischem Zeitpunkt
Die interne Architektur von Tailscale verteilt die Netzwerke auf verschiedene Instanzen, die jeweils von einer eigenen SQLite-Datenbank verwaltet werden. Zur Datensicherung erstellte das System alle paar Minuten vollständige Snapshots der Datenbanken. Sobald eine Beschädigung auftrat, musste die betroffene Instanz gestoppt und repariert werden. Während der Ausfallzeiten konnten sich neue Geräte nicht mit dem Netzwerk verbinden und Administratoren verloren den Zugriff auf die Web-Konsole.
Bei der Fehlersuche arbeitete Tailscale eng mit den SQLite-Entwicklern zusammen und schloss gängige Theorien wie fehlerhafte POSIX-Locks oder Thread-Sicherheitsverletzungen systematisch aus. Einen entscheidenden Hinweis lieferte schließlich eine neu implementierte Transaktions-Pipeline. Diese zeigte bei zwei Vorfällen, dass bereits erfolgreich geschriebene und bestätigte Daten bei nachfolgenden Transaktionen einfach spurlos verschwanden, ohne dass SQLite eine Fehlermeldung ausgegeben hatte. Zudem wiesen die Metriken darauf hin, dass bei Checkpoints fälschlicherweise mehr Seiten kopiert wurden, als im Write-Ahead-Log (WAL) vorhanden waren.
Um den Fehler registrieren zu können, entwickelten die SQLite-Entwickler mit finanzieller Unterstützung von Tailscale ein neues Protokollierungstool für das virtuelle Dateisystem tmstmpvfs. Dieses zeichnete alle Schreib- und Kopieraktivitäten während des Checkpoint-Prozesses auf. Beim nächsten Ausfall lieferten die Logs den Beweis für eine seltene Race-Condition im SQLite-Quellcode. Dieser sogenannte WAL-Reset-Bug existierte bereits seit der Version 3.7.0 vom Juli 2010 unentdeckt im Code.
Der Fehler trat auf, wenn eine Schreibtransaktion zu einem kritischen Zeitpunkt während eines Checkpoints stattfand und den Kopiervorgang so verwirrte, dass Seiten als kopiert markiert wurden, obwohl dies nicht der Fall war. Tailscale geriet nur deshalb in diese Falle, weil sie das Checkpointing manuell und sehr aggressiv steuerten.
Wir öffnen unsere neue Community für weitere Mitglieder! Möchtest du in konstruktiver und respektvoller Atmosphäre mit anderen IT-Experten über deine Themen sprechen? Sei dabei und melde dich an!
- Anzeige Hier geht es zu Hacking & Security: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.