Anfang des Jahres entdeckte das Security-Unternehmen Theori eine Sicherheitslücke im Linux-Kernel, die später als „Copy Fail“ bekannt werden sollte. Die Lücke erlaubte unprivilegierten Nutzern, Root-Rechte zu erlangen. Theori meldete sie am 23. März an die Kernel-Entwickler, woraufhin sie am 1. April im aktuellen Entwicklungszweig des Kernels behoben wurde; einige Tage später portierten die Kernel-Entwickler die Fixes auch auf die Versionszweige 6.18 und 6.19. Das dafür zuständige Linux-Team vergab eine eindeutige Nummer für die Schwachstelle (CVE-2026-31431) und veröffentlichte am 22. April eine Mitteilung dazu, die unter anderem auf die Fixes verwies.

Eine optimal abgelaufene koordinierte Offenlegung (coordinated disclosure), könnte man meinen, doch als Theori am 29. April sehr öffentlichkeitswirksam Copy Fail samt einem Beispielexploit publizierte, erwischte es viele Linux-Distributionen und deren Nutzer kalt: Die von den Distributionen verteilten Kernel enthielten die Fixes genauso wenig wie einige der vom Kernel-Team angebotenen „longterm“-Versionen. Für letztere wurden am 30. April Fixes nachgereicht; einige Distributionen benötigten deutlich länger, um aktualisierte Kernel auszuliefern und strickten mit heißer Nadel Workarounds, um betroffene Systeme notdürftig zu kitten.

In der Folge wurde Theori viel kritisiert. Nicht zu Unrecht (dazu später mehr), aber Copy Fail war kein außergewöhnliches Versagen, dessen Ursache man allein Theori anlasten kann. Dass es im Disclosure-Prozess rund um Kernel-Lücken allgemein knirscht, zeigte sich schon wenige Tage nach Copy Fail, als die Lücken „Dirty Frag“ und „Copy Fail 2“ publiziert wurden. An beiden war Theori nicht beteiligt und auch in diesen beiden Fällen lief die öffentliche Bekanntgabe alles andere als rund.

Das war die Leseprobe unseres heise-Plus-Artikels "Vom Umgang mit Sicherheitslücken im Linux-Kernel". Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.