In Linux wurde zum 13. Mai 2026 eine weitere Kernel-Schwachstelle (CVE-2026-46300) bekannt, die eine lokale Rechteausweitung auf Root im Linux-Kernel ermöglicht. Die als "Fragnesia" bezeichnete Schwachstelle gehört zur gleichen Klasse wie die kürzlich bekannt gewordene "Dirty Frag"-Schwachstelle. Zur Zeit gibt es wohl nur Mitigationen gegen ein veröffentlichtes Proof of Concept (PoC), da die Patches gerade erst in die Distributionen einlaufen.
Fragnesia, eine LPE Kernel-Schwachstelle (CVE-2026-46300)
Die zum 13. Mai 2026 bekannt gewordene Sicherheitslücke (CVE-2026-46300) im Linux-Kernel, wurde von Sicherheitsforschern von V12 entdeckt und veröffentlicht (siehe folgender Tweet).
Sicherheitsforscher William Bowling vom V12-Sicherheitsteam ist mit KI-Unterstützung auf diese dritte Schwachstelle im Linux-Kernel gestoßen und hat ein Proof-of-Concept im pocs-Repository von V12 auf GitHub veröffentlicht. Die Schwachstelle gehört zur gleichen Klasse wie die kürzlich bekannt gewordene "Dirty Frag"-Schwachstelle und wurde knapp eine Woche nach deren Veröffentlichung, pünktlich zum Feiertag in Deutschland, bekannt.
Die Sicherheitslücke benötigt keine Race Condition zur Ausnutzung, so dass ein veröffentlichtes Proof of Concept einer der zuverlässigsten Exploits zur lokalen Rechteausweitung der letzten Jahre ist. Der Name "Fragnesia" resultiert daraus, dass Fragmente im Cache vergessen werden. "Fragnesia", ermöglicht es lokalen Benutzern ohne Administratorrechte ihre Berechtigungen auf Root-Ebene auszuweiten.
Schwachstelle in der XFRM-ESP-in-TCP-Verarbeitung
Die Schwachstelle (CVE-2026-46300) nutzt einen Logikfehler im Linux-XFRM-ESP-in-TCP-Subsystem aus, um beliebige Byte-Schreibvorgänge in den Kernel-Seiten-Cache von schreibgeschützten Dateien durchzuführen, ohne dass eine Race Condition erforderlich ist.
Die Technik erweitert laut Entdecker die Klasse der Page-Cache-Schreibfehler, zu der auch "Dirty Pipe" gehört: Wenn ein TCP-Socket in den espintcp-ULP-Modus wechselt, nachdem Daten bereits aus einer Datei in die Empfangswarteschlange eingefügt wurden, verarbeitet der Kernel die in der Warteschlange befindlichen Dateiseiten als ESP-Chiffretext. Das AES-GCM-Keystream-Byte an der Zählblockposition 2, Byte 0, wird direkt per XOR in die zwischengespeicherte Dateiseite eingefügt. Durch Auswahl der IV-Nonce zur Erzeugung eines gewünschten Keystream-Bytes kann jedes Zielbyte in der Datei auf einen beliebigen Wert gesetzt werden – ein Byte pro Trigger-Aufruf.
Der Exploit erstellt eine Lookup-Tabelle mit 256 Einträgen, die jedes mögliche Keystream-Byte dem entsprechenden Nonce zuordnet, und durchläuft dann eine Payload, wobei für jedes zu ändernde Byte der Splice/ULP-Wettlauf ausgelöst wird. Er schreibt einen kleinen positionsunabhängigen ELF-Stub (setresuid/setresgid/execve /bin/sh) über die ersten 192 Bytes von /usr/bin/su im Seitencache und ruft dann execve("/usr/bin/su") auf, um eine Root-Shell zu erhalten. Die Änderung des Seitencaches wird nicht auf die Festplatte zurückgeschrieben; die Binärdatei auf der Festplatte bleibt unberührt.
Auf die Schwachstelle reagieren
Details sind in diesem GitHub-Dokument der Entdecker sowie im PoC auf GitHub nachlesbar. Weitere Infos sind auf Openwall zu finden. Betroffen sind alle Linux-Distributionen die für Dirty Frag anfällig waren. Es sind die gleichen Abhilfemaßnahmen wie bei Dirty Frag möglich.
rmmod esp4 esp6 rxrpc printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
Der der Patch für den Kernel ist aber wohl noch nicht in die Distributionen übernommen worden. Debian hat bisher nur diesen Eintrag mit den Beschreibungen der betroffenen Linux-Versionen sowie einer Verlinkung auf weitere Seiten bei kernel.org mit Fixes veröffentlicht. Von Alma Linux gibt es diesen Beitrag mit Hinweisen und Redhat hat diesen Eintrag im Customer-Portal veröffentlicht. Von Ubuntu gibt es ebenfalls einen Artikel.
Eine weitere Beschreibung gibt es auf TuxCare.com. Von Microsoft gibt es in diesem Tweet einige Informationen zur Schwachstelle und den Hinweis, dass ein Patch verfügbar sei, sowie der Defender die Fragmente der bisher bekannten PoCs erkenne.
Ähnliche Artikel:
Linux-Schwachstelle Copy Fail (CVE-2026-31431) erlaubt Rooting
Dirty Frag: Lokale Rechteausweitung im Linux-Kernel (CVE-2026-43284, CVE-2026-43500)
MVP: 2013 – 2016
Ich möchte mich beschweren. Es ist noch Donnerstag, die letzten drei Wochen kamen Kernel Bugs immer am Freitag ;-)
Die Einschläge werden immer dichter …
KI sei Dank. Das ist nur der Anfang und wird noch schlimmer werden(nicht nur bei Open Source, überall).
zumindest bei OoenSource ist es doch positiv, wenn so etwas gefunden und schnell behoben wird.
?
Das ist genau der Punkt. Während Kernel Updates sehr schnell und die Distros mit ein paar Tagen Verzögerung auch sehr schnell liefern, ist das bei Closed-Source genau umgekehrt. Da brauchen Hersteller Monate, wenn Sie nicht schon zuvor alles abgestritten oder sogar aktiv mit SLAPPs bekämpft haben.
Also jeden Fund, feiern!
Hat nix mit Open oder Closed Source zu tun!
Etwas verschobene Ansicht.
Alma Linux hat hier bei allen drei Kernel-Bugs vorbildlich reagiert und besonders schnell einen Fix eingepflegt. Werde ich wohlwollend in Erinnerung behalten, falls ich mal wieder Linux aufsetzen muss.
An die Linuxspezialisten hier (Thomas Jakobs?), Kommentare hierzu, oder andere lobenswerte Linuxdistributionen?
KDE neon oder NixOS. Eigentlich sind aber alle Linux-Distributionen lobenswert.
TUXEDO OS
Noch unausgegorene Patchvorschläge als Erster einbauen und an alle verteilen halte ich für alles andere als vorbildlich.
Der vom Entdecker vorgeschlagene Patch funktioniert so nicht wirklich, wie Hyunwoo Kim mittlerweile klargestellt hat:
https://lore.kernel.org/all/agRfuVOeMI5pbHhY@v4bel/
Das war bei den vorherigen Bugs in den betroffenen Modulen zuerst auch nicht anders.
Die von den meisten eh nicht genutzen Module vollständig deaktivieren ist deshalb derzeit die besser Lösung. Erst recht wenn es Server betrifft, die man nicht ständig mal neu booten kann.
Dürfte noch interessant werden ob da noch jemand einen möglichen Angriffspunkt an die betroffenen Interfaces von außen findet. Dieser Kandidat bekommt dann volle 10.0 Punkte.
Zumindest in /net/core ist man ja mittlerweile angekommen. Und das Problem dürfte damit wohl nicht nur wie bisher Kernel ab Version 4.11.0, sondern wohl alle betreffen.
Jeder der auf IPSEC angewiesen ist oder es unnötigerweise ohne es zu wissen aktiviert hat derzeit ein nicht wirklich kalkulierbares Problem.
Möge keiner auch noch in Wireguard oder wo anders im Kernel Bugs suchen und finden…
Module deaktiveren bei Servern: ja, Profis können das sicher. Für Otto Normallinuxuser ist das schon ein wenig herausfordernd. Also habe ich mal gefragt:
"you are a linux specialist and have a thorough unterstanding of kernel modules. Your client is an average linux user using mint oder ubuntu. List all modules which can be safely disabled without causing problems for said client.".
Das liefert mit bei Claude genau 50 Module, viele legacy, mit kurzem Abriss, was sie machen, und ob es ratsam ist (Einschränkungen). Dazu eine Anleitung, wie ich sie blackliste und vorher prüfe, ob das überhaupt notwendig ist.
Von einigen Modulen weiß ich jetzt, dass ich sie vermutlich nicht brauche (floppy, anyone?). Aber trau ich mich jetzt trotzdem?
"Für Otto Normallinuxuser ist das schon ein wenig herausfordernd."
Otto Normallinuxuser ist froh, sein Linux Mint oder Ubuntu ans Laufen zu kriegen (und zu betreiben). Warum sollte der einen Linux Server betreiben? Und wann ja, dann sollte er sich entsprechend informieren.
Auch mit 40 Jahren Erfahrung in verschiedensten Systemen, ich will nicht dauernd umkonfigurieren, patchen, neu aufgetretene Probleme beheben, usw. Es hat der Hersteller/Distromaintainer zu sorgen, dass alles stabil und sicher bleibt. Ob Windows, Linux, MacOsS, FreeBSD – man kann sich anpassen, und Virtualisierung hilft.
Falls keiner das kann, ist Airgapping aller Kisten bis auf einen vernagelten Zugangsknoten die bessere Verwendung meiner Lebenszeit.
Nenn uns den Anwendungsfall, in dem Ottonormallinuxuser das tun sollte.
Der Post geht eher mal wieder in die übliche Trollerei, ohne sich auch nur ansatzweise mit dem Thema hier beschäftigt zu haben – wie auch so ziemlich alle anderen "Anonym"-Posts hier zu diesem Beitrag.
Das steht in dem Beitrag auf den sich mein Klon bezieht :P
Was meinst du genau mit lobenswert?
Grundsätzlich gilt: Je größer/bekannter/verbreiteter desto besser, weil allgemeiner aufgebaut und Probleme fallen schneller auf. Wenn ein Firma dahintersteht noch besser, weil sich dann auf jeden Fall jemand kümmern kann.
Bereits genannt
KDE Neon: Ubuntu mit allerneuestem KDE Kram = ggf. instabil
NixOS: Wird häufiger empfohlen ist aber ziemlich Eigen = eher Nix(OS) für Anfänger
Tuxedo: Ubuntu ohne den (manche störenden) Nervkram, neuerer Kernel, eigens gepflegte Software, auf maximale Kompatibiltät ausgelegt = Mglw. Top Antwort
Zusätzlich
Debian: Hochgradig stabil = Ggf. Probleme mit relativ aktueller Hard- und Software
Mint (Ubuntu) bzw. Mint Debian Edition: Relativ einfach, guter Allrounder = Empfehlung, DE ohne den (manche störenden) Nervkram von Ubuntu
CachyOS: Häufig empfohlen, (ggf. komplexe) Arch Basis = Eher nix für Anfänger wie alle Archs
Fedora: Manchmal empfohlen, neueste Software = Nix für Anfänger
Für Server
Debian (minimal): Extrem stabil, sehr geringe Voraussetzungen je nach Anwendung
RedHat/Alma/Rocky/Oracle: Alles mehr oder weniger dasselbe, Auswahl je nachdem ob und welcher Support benötigt wird
Alpine: Schmales, sicheres System für Cloud-/Containerkram
usw. usf.
Ok, Frage war ungenau. Aus meiner Sicht muss das OS plus GUI stabil *und* sicher sein, oder würdest du bei einem Auto oder Flugzeug ein *oder* akzeptieren? Ob Windows, Linux, MacOsS, FreeBSD ist hier nicht entscheidend, man kann sich anpassen, und Virtualisierung hilft auch.
Also, welcher Hersteller/Distromaintainer kann das gut und reagiert schnell auf Probleme? Falls keiner, ist Airgapping meiner Kisten bis auf einen vernagelten Zugangsknoten die bessere Verwendung meiner Lebenszeit.
Ähnliche Ecke und hässlich wenn man Webserver betreibt: Auch in NGINX gibt es eine unauthenticated RCE. CVE-2026-42945 (aka NGINX rift). Da geht es über HTTP, also ggf. deutlich einfacher auszunutzen als Kernel-Kram, welcher einen lokalen Zugriff benötigt. Natürlich auch kombinierbar.
Apache hat auch gerade wieder CVE-Schnupfen.
Pi-hole hat vor drei Tagen auch ein Notfallupdate wegen mehrerer schwerer Sicherheitslücken in dnsmasq bekommen. Sowas hatte ich in ~10? Jahren glaube ich noch nie!
https://www.kb.cert.org/vuls/id/471747
Fedora hat in den letzten paar Wochen auch mehr kritische Updates erhalten als im letzten Dreivierteljahr zusammen.
Der Kernel unter SPARKY-Linux (testing) ist bereits bei v7.0.6-1.
Ansonsten gilt nach jedem Start (unter DEBAIN): sudo apt-get update && sudo apt-get upgrade !
Sicherheitsrelevante Syteme können und sollen natürlich mitigiert werden, für "Otto-Normal-Desktops" sehe ich da eher weniger Probleme.
Der Spaß geht weiter :)
https://www.phoronix.com/news/Linux-ssh-keysign-pwn
Muss heute (Fr.) gesundheitlich eine Pause einlegen und liege den gesamten Tag im Bett. Hat sich schon einige Tage angekündigt (irgend ein Magen-Darm-Pathogen), vorige Woche hatte es meine Frau getroffen. Mich schießt so etwas dann mit Nervenschmerzen aus dem Rennen).
Linux-Schwachstelle ssh-keysign-pwn (CVE-2026-46333) ermöglicht Fremdzugriff auf Dateien
Kein Ding, gute Besserung! Für die Leser hier ist es aber wahrscheinlich dennoch interessant.
Danke und gut, dass es anscheinend schon gefixed wurde.
Gute Besserung, @Günther Born
Gute Besserung und langsam machen!
Gute Besserung!
Wir kommentieren weiter, dann wird dir nach der Genesung nicht langweilig. GRINS.
Aber die Gesundheit geht vor!!!
Auch von mit gute Besserung.
Arch Linux scheint der Zeit voraus zu sein, wenn man die Veröffentlichungen (nicht nur hier!) in diesen Tagen liest.
Bei Arch Linux war Fragnesia mit Linux Kernel 7.0.6 gepatcht. Doch darauf folgte schon die Version 7.0.7, die eine neue Lücke enthält. Und während bei kernel.org dagegen heute 7.0.8 veröffentlicht wurde, haben die fleißigen Leute bei Arch Linux die 7.0.7 mit entsprechendem Update gegen Abend freigegeben.
Linux 7.0.8 ist bei Arch jetzt in Bearbeitung und wird wohl in den kommenden Tagen freigegeben.
Link zu kernel.org: cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.8
Link zu arch linux 7.0.7.arch2-1: https://archlinux.org/packages/core/x86_64/linux/
Langweilig wird es uns in diesem Jahr auch nicht werden …
Linux Arch ist hier mittlerweile auch auf 7.0.8. Auch Debian ist hier mittlerweile up to date.
Der heutige ptrace Bug ist nochmals wesentlich heftiger.
Man kann ihn nur per sofortigen Update+Reboot oder Hotpatch fixen. Es ist keine wirklich wirksame Mitigation bekannt. Er betrifft alle Kernels seit 2020. Bereits mit dem veröffentlichten PoC lassen sich beliebige Dateien im System als root auslesen. Einen noch folgenden Exploit mit dem auch noch als root beliebig beschrieben werden kann würde zumindest ich nicht sicher ausschließen.
Aber Vorsicht: Für die Bugs um die es hier im Beitrag geht gibt es davon völlig unabhängig weiterhin keinen sicher funktionierenden endgültigen Bugfix.
Wer IPSEC nicht zwingend braucht sollte deshalb weiterhin die vier Module algif_aead, esp4, esp6 und rxrpc deaktivieren bzw. deaktiviert lassen. Und das gilt mittlerweile für alle Kernels seit mindestens 2013.
*ttps://tuxcare.com/de/blog/fragnesia-cve-2026-46300-is-a-new-linux-kernel-lpe/
Um diese Zeit war ich schon im Bett und habe das Update heute Morgen zum Computerstart vorgenommen. Hat nur kurz gedauert und Arch funktioniert problemlos; ich konnte mich bei der Installation auf die für mich relevanten Funktionen beschränkten. Ergebnis ist ein System, das mit 8GB auskommt.
Bei openSUSE Tumbleweed habe ich nach dem Update und einem Neustart eine Auflösung von nur noch 640×480 und diese Auflösung ist die einzige, die man einstellen kann, also absolut unbenutzbar.
Die Ursache ist die aktuell inkompatible Kombination von Kernel v7.0.x und nvidia-drivers-G06.
openSUSE hat einfach die Kernelversion von 6 auf 7 erhöht, ohne zu beachten, ob der proprietäre Nvidia-Treiber auch zu dem neuen Kernel passt.
Das finde ich besonders ärgerlich, weil ich extra vorher den Nvidia-Treiber v580 mit einem Schutz versehen hatte ("sudo zypper addlock *nvidia*"), damit kein neuer eventuell inkompatibler Treiber für die Grafikkarte installiert wird.
Lösung:
Kernel-longterm 6.18 statt Kernel-default 7 muss installiert werden und dazu dann passend nvidia-open-driver-G06-signed-kmp-longterm.
Den Kernel konnte ich auch nicht einfach so über YAST umswitchen, sondern musste über diese Webseite gehen, Expert-Download, Binärpaket runterladen:
*ttps://software.opensuse.org/package/kernel-longterm
Der Weg über das Repository funktionierte nicht, weil der dort angegebene Pfad nicht mehr stimmt. Da sollte der Maintainer des Paketes mal nachbessern.
*ttps://software.opensuse.org/package/kernel-longterm
Es wäre auch besser, wenn openSUSE so einen LTS-Kernel selber ins eigene Repository einfügen würde, anstatt dort nur den neuesten Kernel-Zweig verfügbar zu machen.
Bei einer Auflösung von 640×480 sind sowohl YAST als auch der Browser nahezu unbenutzbar und in einer Konsole kenne ich nicht die Namen der nötigen Pakete auswendig.
Man muss dann mit einem zweiten Computer recherchieren, woran es liegen könnte und wie man es reparieren könnte und dann in der Konsole ziemlich herumfrickeln, bis es wieder funktioniert.
Bei reddit sah ich einen Beitrag, der ebenfalls bestätigt, dass der neue Kernel 7 noch nicht zu dem Nvidia-Treiber passt, weil es instabil läuft, wenn überhaupt.
*ttps://www.reddit.com/r/openSUSE/comments/1tfmmzz/psa_kernel_706_nvidia_58015903_open_g06_signed/
Nvidia muss mal endlich die bescheuerten Treiber zeitnah mit den neuen Kerneln kompatibel machen.
openSUSE hat zwar ein gut funktionierendes automatisches Qualitätsssicherungsverfahren "OpenQA", aber leider ist dort der externe proprietäre Nvidia Treiber kein Bestandteil davon, so dass solche Inkompatibilitäten mit dem Grafiktreiber nicht erkannt werden und der nvidia-Experte bei openSUSE, der das Repository "pflegt" scheint etwas schlampig zu arbeiten.
Die Bezeichnung "-default" als Kernel-Anhängsel zieht den Kernel zu leicht von Version 6 auf 7 hoch, ohne Rücksicht auf Verluste und der User steht dann urplötzlich vor einem unbenutzbaren System, weil der Nvidia-Treiber nicht mehr passt.
Als Fallback-Auflösung sollte besser 800×600 oder 1024×720 eingestellt sein anstatt sehr mickrige unbenutzbare 640×480.
Deswegen sollte man besser immer "-longterm" nehmen, also LTS-Kernel benutzen und nicht die bleeding edge Kernel.
Außerdem zusätzlich den LTS-Kernel und den Nvidia-Treiber mit einem lock versehen, damit die nicht plötzlich auf inkompatible Zweige updaten.
sudo zypper addlock kernel-longterm
sudo zypper addlock nvidia-open-driver-G06-signed-kmp-longterm
Wegen dieses unerfreulichen Ereignisses und auch wegen der fehlenden und geblacklisteten patentierten Codecs kann ich openSUSE jetzt nicht mehr empfehlen.
Ebenso ist die Kombination von Linux und Nvidia manchmal echt nervig.
Bei einem AMD-Grafikchip hat man dieses Problem nicht, weil der dazu passende Grafiktreiber bereits im Kernel vorhanden ist.