Der Netzwerkdiensteanbieter Tailscale hat nach monatelanger Untersuchung einen 16 Jahre alten Programmierfehler in der Datenbank SQLite gefunden. Unter bestimmten Bedingungen führte der Fehler zu Datenkorruption und beeinträchtigte die Netzwerkstabilität von Tailscale über Monate hinweg erheblich. Besonders bitter: SQLite lief bereits seit 2022 als primäre Datenbank im Einsatz und galt als bewährt und zuverlässig, ohne dass am Code irgendetwas geändert worden war.
Beschädigungen ohne erkennbare Ursache
Im August 2025 meldete die S3-Backup-Pipeline erste Datenbankbeschädigungen, die sich in den folgenden sechs Monaten auf insgesamt 19 Fälle summierten. Die Ursachensuche gestaltete sich besonders schwierig, weil keine Änderungen am eigenen Code vorlagen und sich der Fehler nicht künstlich reproduzieren ließ.
Tailscales interne Architektur verteilt Netzwerke auf verschiedene Instanzen, die jeweils eine eigene SQLite-Datenbank verwalten. Zur Absicherung erstellte das System alle paar Minuten vollständige Snapshots. Trat eine Beschädigung auf, musste die betroffene Instanz gestoppt und repariert werden, in dieser Zeit konnten sich keine neuen Geräte mit dem Netzwerk verbinden, und Administratoren verloren den Zugriff auf die Web-Konsole.
Eine Race Condition seit 2010
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. Den entscheidenden Hinweis lieferte eine neu implementierte Transaktions-Pipeline: Bei zwei Vorfällen zeigte sich, dass bereits erfolgreich geschriebene und bestätigte Daten bei nachfolgenden Transaktionen spurlos verschwanden, ohne dass SQLite eine Fehlermeldung ausgab. Die Metriken deuteten zudem darauf hin, dass bei Checkpoints fälschlicherweise mehr Seiten kopiert wurden, als im Write-Ahead-Log vorhanden waren.
Um den Fehler überhaupt sichtbar zu machen, entwickelten die SQLite-Entwickler mit finanzieller Unterstützung von Tailscale ein neues Protokollierungstool für das virtuelle Dateisystem, genannt tmstmpvfs. Es zeichnete sämtliche 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 selbst, den sogenannten WAL-Reset-Bug. Dieser existierte bereits seit Version 3.7.0 vom Juli 2010, also seit rund 16 Jahren, unentdeckt im Code.
Aggressives Checkpointing als Auslöser
Der Fehler trat auf, wenn eine Schreibtransaktion zu einem kritischen Zeitpunkt während eines Checkpoints stattfand. Das brachte den Kopiervorgang durcheinander, sodass Seiten fälschlich als kopiert markiert wurden, obwohl das nicht der Fall war. Tailscale geriet vor allem deshalb in diese Falle, weil das Unternehmen das Checkpointing manuell und sehr aggressiv steuerte, ein Nutzungsmuster, das viele andere SQLite-Anwender vermutlich nie in dieser Form erreichen. Der Fall zeigt, wie selbst jahrzehntelang bewährte, weit verbreitete Software noch tief verborgene Bugs enthalten kann, die erst unter sehr spezifischer, intensiver Nutzung zutage treten.