Ubuntu-Kernelupdates schließen neue Sicherheitslücken in mehreren LTS-Zweigen. Canonical hat am 25. August 2026 mehrere Ubuntu Security Notices für reguläre und spezialisierte Linux-Kernel veröffentlicht. Betroffen sind unter anderem Ubuntu 24.04 LTS, Ubuntu 22.04 LTS und Azure-Kernel für Cloud-Systeme. Administratoren müssen die Updates installieren und die Systeme anschließend neu starten.
Die neuen Meldungen betreffen nicht nur klassische Serverinstallationen. Canonical nennt auch Kernel für Microsoft Azure, Azure CVM, Azure FIPS, AWS und NVIDIA-Tegra-Systeme. Damit ist die Aktualisierung für viele Umgebungen im Bereich Linux-Server und Ubuntu-Systeme relevant. Besonders wichtig sind die Schwachstellen in Open vSwitch und SCTP, weil beide Komponenten in Netzwerk- und Serverumgebungen vorkommen können.
Canonical verteilt Kernel-Fixes für Ubuntu 24.04 und 22.04 LTS
Die zentrale Meldung für aktuelle LTS-Systeme ist USN-8643-4. Canonical führt dort Ubuntu 24.04 LTS und Ubuntu 22.04 LTS auf. Die korrigierten Pakete umfassen unter anderem linux-aws-6.8, linux-azure-fde, linux-azure-fde-6.8, linux-azure-fips und linux-nvidia-tegra. Die behobenen Fehler liegen laut Canonical in den Bereichen Netzwerktreiber, Open vSwitch und SCTP.
Für Ubuntu 22.04 LTS gibt es zusätzlich USN-8658-3. Diese Meldung nennt linux-azure, linux-azure-fde und linux-nvidia-tegra-igx. Auch dort korrigiert Canonical Schwachstellen in Open vSwitch und SCTP. Für Ubuntu 26.04 LTS ergänzt USN-8659-3 den Azure-Zweig mit einem Fix für CVE-2026-64531. Der Konzern beschreibt diese Meldung als einzelne Kernel-Sicherheitslücke im Open-vSwitch-Subsystem.
| USN | Betroffene Versionen | Pakete und Schwerpunkt |
|---|---|---|
| USN-8643-4 | Ubuntu 24.04 LTS und 22.04 LTS | AWS-, Azure-FDE-, Azure-FIPS- und NVIDIA-Tegra-Kernel |
| USN-8658-3 | Ubuntu 22.04 LTS | Azure-, Azure-FDE- und NVIDIA-Tegra-IGX-Kernel |
| USN-8659-3 | Ubuntu 26.04 LTS | Azure- und Azure-FDE-Kernel mit Open-vSwitch-Fix |
| USN-8666-2 | Ubuntu 20.04 LTS und 18.04 LTS mit Ubuntu Pro-Kontext | Azure-5.4- und Azure-FIPS-Kernel für ältere LTS-Zweige |
Der Neustart ist keine Formsache. Canonical schreibt in den Update-Anweisungen, dass ein Standard-Systemupdate durchgeführt werden muss und danach ein Neustart erforderlich ist. Der Grund liegt im Kernel selbst. Geladene Kernelbestandteile werden nicht vollständig ersetzt, solange das System mit dem alten Kernel läuft. Erst nach dem Neustart startet die Maschine mit dem aktualisierten Kernel und den korrigierten Modulen.
Canonical weist zudem auf eine ABI-Änderung hin. Die Kernelupdates erhalten dadurch neue Versionsnummern. Drittanbieter-Kernelmodule müssen neu kompiliert und neu installiert werden. In Standardinstallationen erledigt das Metapaket den Wechsel normalerweise automatisch. Systeme mit manuell entfernten Standard-Metapaketen oder proprietären Zusatzmodulen sollten dennoch genauer geprüft werden. Das betrifft zum Beispiel spezielle Storage-Treiber, Sicherheitsagenten, Virtualisierungskomponenten oder Monitoring-Module.
- CVE-2026-64531 betrifft Open vSwitch und hat bei Ubuntu eine hohe Priorität.
- CVE-2026-53224 betrifft SCTP und hat bei Ubuntu ebenfalls eine hohe Priorität.
- CVE-2026-53246 betrifft SCTP und wird bei Ubuntu mit mittlerer Priorität geführt.
- CVE-2026-53247 betrifft einen MediaTek-Ethernet-Treiber und wird bei Ubuntu niedriger priorisiert.
- Neustartpflicht gilt nach dem Standardupdate, weil der Kernel ersetzt wird.
- Drittmodule brauchen nach der ABI-Änderung besondere Kontrolle.
Netzwerk- und Cloud-Systeme sollten die Updates priorisieren
Die technische Einordnung zeigt, warum diese Updates nicht als Routinepaket abgetan werden sollten. CVE-2026-64531 betrifft Open vSwitch. Open vSwitch wird häufig in virtualisierten und cloudnahen Netzwerken eingesetzt. Canonical beschreibt einen Fehler bei verschachtelten Action-Attributen. Übergrößen können dazu führen, dass spätere Verarbeitungsschritte einen anderen Datenstrom sehen als zuvor validiert wurde. Ubuntu bewertet die Schwachstelle mit hoher Priorität.
CVE-2026-53224 und CVE-2026-53246 betreffen SCTP. Beide Lücken hängen mit der Verarbeitung von COOKIE_ECHO und eingebetteten INIT-Daten zusammen. Canonical beschreibt mögliche Out-of-bounds-Lesezugriffe und mögliche Speicherbeschädigung bei fehlerhaften Längenangaben. Der CVSS-Wert fällt hoch aus. Ubuntu stuft die praktische Priorität aber unterschiedlich ein. Das zeigt, dass CVSS und Ubuntu-Priorität nicht immer identisch sind.
CVE-2026-53247 wirkt auf den ersten Blick ebenfalls kritisch, trägt bei Ubuntu aber nur niedrige Priorität. Canonical begründet das mit den Ausnutzungsvoraussetzungen. Für die Auslösung sind Root-Rechte oder CAP_SYS_ADMIN nötig, etwa zum Entfernen eines MediaTek-Plattformgeräts oder zum Entladen eines Kernelmoduls. Diese Einschränkung reduziert die praktische Gefahr auf vielen Servern deutlich. Trotzdem gehört der Fix in reguläre Wartungsfenster, weil Kernel-Speicherfehler grundsätzlich ernst bleiben.
Für Administratoren ergibt sich daraus eine klare Reihenfolge. Zuerst sollten Internet-nahe Server, Cloud-Instanzen, Virtualisierungshosts, Kubernetes-Knoten, Systeme mit Open vSwitch und Maschinen mit SCTP-Nutzung geprüft werden. Danach folgen weniger exponierte Workloads. In Azure-Umgebungen muss zusätzlich kontrolliert werden, ob der eingesetzte Kernelzweig wirklich mit den neuen Paketversionen übereinstimmt. FIPS-Varianten und Pro-Pakete haben eigene Paketnamen und eigene Rolloutpfade.
Der Kontext passt zu den Sicherheitsmeldungen der vergangenen Wochen. Ubuntu-Systeme standen zuletzt mehrfach durch Paket- und Kernelupdates im Fokus, unter anderem durch ImageMagick-Lücken mit möglicher Codeausführung unter Ubuntu. Die neue Kernelrunde ist praktischer angelegt: Updates einspielen, Drittmodule prüfen, Neustart planen und danach die laufende Kernelversion verifizieren.
Für produktive Systeme reicht deshalb kein bloßer Paketdownload. Nach dem Wartungsfenster sollten Administratoren mit uname -r, Paketlisten und Monitoring prüfen, ob der neue Kernel tatsächlich aktiv ist. Maschinen mit Livepatch, eigenen Kernelmodulen oder verzögerten Reboots brauchen eine separate Kontrolle. Canonical liefert die korrigierten Pakete aus. Der Schutz greift aber erst vollständig, wenn der aktualisierte Kernel läuft.