Linux-Kernel-Sicherheitslücken „Copy-Fail“ und „Dirty Frag“: Warum Sie jetzt handeln müssen

Ein aktueller Fund in der Cybersicherheit sorgt derzeit weltweit für Aufsehen bei Administratoren und IT-Verantwortlichen. Die als „Copy-Fail“ (CVE-2026-31431) und „Dirty Frag“ (CVE-2026-43284) bekannt gewordenen Schwachstellen betreffen den Linux-Kernel und werden bereits aktiv für Angriffe genutzt.

Kontaktieren Sie uns noch heute, wir unterstützen Sie bei der Absicherung Ihrer Systeme!

Beide Schwachstellen ermöglichen lokale Rechteausweitung bis hin zu Root-Rechten und stellen insbesondere für produktive Datenbankumgebungen ein erhebliches Risiko dar.

Der Hintergrund der „Copy-Fail“ Schwachstelle

Das Problem liegt tief in der Krypto-Schnittstelle des Linux-Kernels, genauer gesagt in der Komponente algif_aead. Ursprünglich wurde dort eine Optimierung eingeführt, um Daten direkt im bestehenden Speicherbereich zu verarbeiten, anstatt sie zu kopieren.
Wie sich herausgestellt hat, führte diese technische Komplexität zu einem kritischen Fehler beim Datentransfer zwischen verschiedenen Speicherzuordnungen. In der Fachwelt wird dieser Fehler als „Copy Fail“ bezeichnet.

Durch Überschneidungen zwischen Quell- und Zielbereichen können Angreifer:

  • Root-Rechte erlangen
  • Den Page-Cache manipulieren
  • Schreibgeschützte Dateien verändern
  • Sicherheitsmechanismen umgehen

Betroffen sind zahlreiche Linux-Kernel-Versionen von 4.14 bis 6.19. Damit sind praktisch alle wichtigen Enterprise-Distributionen betroffen, darunter:

  • Red Hat Enterprise Linux
  • Ubuntu
  • Oracle Linux
  • Amazon Linux
  • SUSE Linux Enterprise Server
  • Debian

Dirty Frag: Die nächste kritische Kernel-Schwachstelle

Dirty Frag beschreibt eine weitere Klasse von Linux-Kernel-Schwachstellen, die in den Subsystemen xfrm-ESP (IPsec) und RxRPC auftreten. Sie wird mit den Kennungen CVE-2026-43284 und CVE-2026-43500 in Verbindung gebracht.

Ein Angreifer kann dadurch:

  • Schreibgeschützte Dateien im Page-Cache manipulieren
  • Sicherheitsrichtlinien umgehen
  • Unmittelbar Root-Rechte erlangen

Besonders kritisch:

  • Ein öffentlicher Proof-of-Concept ist verfügbar
  • Viele Linux-Systeme seit etwa 2017 sind betroffen
  • Frühere Schutzmaßnahmen gegen Copy Fail helfen nicht
  • Zum Zeitpunkt der Veröffentlichung standen zunächst keine vollständigen Patches bereit

Wir stehen dazu mit den Herstellern in ständigem Kontakt.

Auswirkungen auf Datenbankumgebungen

Die genannten Schwachstellen betreffen grundsätzlich alle Datenbankumgebungen, die auf Linux betrieben werden, darunter:

  • Oracle Database auf Oracle Linux
  • Oracle RAC
  • Oracle Exadata
  • Oracle Cloud Infrastructure (OCI)
  • Oracle Database Appliance (ODA) (Update vorraussichtlich ab 18.05. verfügbar)
  • VMware- und Bare-Metal-Installationen
  • Hybrid- und Multi-Cloud-Umgebungen
  • Weitere relationale Datenbanksysteme wie SQL Server Linux Edition, PostgreSQL und MySQL

Ein erfolgreicher Angriff kann zu folgenden Konsequenzen führen:

  • Zugriff auf vertrauliche Datenbankdaten
  • Manipulation von Datafiles, Redo Logs und Backups
  • Kompromittierung von Cluster- und RAC-Umgebungen
  • Seitliche Bewegung innerhalb der Infrastruktur
  • Verletzung regulatorischer Anforderungen (z. B. DSGVO, ISO 27001)

Gerade produktive Datenbanksysteme mit hohen Verfügbarkeitsanforderungen sollten diese Risiken mit höchster Priorität behandeln.

Unterstützung bei der Absicherung Ihrer Datenbank-Systeme

Wir unterstützen Sie bei der schnellen und sicheren Umsetzung aller erforderlichen Maßnahmen.
Unsere Leistungen umfassen:

  • Sicherheitsanalyse Ihrer Oracle- und Linux-Umgebung
  • Bewertung der konkreten Betroffenheit
  • Planung und Durchführung von Kernel-Updates
  • Unterstützung bei Oracle-Datenbank- und Grid-Infrastructure-Patches
  • Durchführung von Wartungsfenstern mit minimalen Ausfallzeiten
  • Prüfung von Hochverfügbarkeits- und Disaster-Recovery-Architekturen

Kontaktieren Sie uns jetzt für Ihre Terminplanung:

Weitere Details zur technischen Einordnung der Schwachstelle können Sie auch direkt in der National Vulnerability Database unter CVE-2026-31431 oder CVE-2026-43284 nachlesen.

Oracle 19.30 Grid Infrastructure und Database Release Update jetzt wieder verfügbar!

Oracle hatte den RU 19.30 zwei Tage nach dem Release wieder zurückgezogen. Grund war ein Bug, der in On-Premises RAC-Datenbanken beim Rolling Update Block Corruption verursachen kann, die dann auch eine ggfs. vorhandene Standby-Datenbank betreffen können. Genaueres hierzu liefert das Dokument MOS KB867473.

Seit gestern (02.02.26) ist der RU nun wieder zum Download bereitgestellt.

Im Artikel KB860153 finden sich Download-Links zum GI- und DB-RU, dem OJVM Patch und dem Windows Bundle Patch Version 19.30 (dieser ist allerdings noch nicht verfügbar).

Wer bereits am ersten Tag den ursprünglichen RU heruntergeladen und eingespielt hatte, wird in KB867473 angehalten, diesen wieder zu deinstallieren und durch den nun verfügbaren (Release-Datum ist hier der 02.02.!) zu ersetzen. Da auch die Version 19.29 bereits betroffen ist, wird hier das Setzen eines Parameters sowie VOR dem nächsten RU die Installation eines One-Off Patches im 19.29er ORACLE_HOME empfohlen.

Oracle Critical Patch Update / Release Update 19.26/21.17/23.7 für Januar 2025 veröffentlicht

Oracle hat planmäßig am 21.1.2025 die neueste Version seiner Critical Patch Updates veröffentlicht. Die Updates betreffen praktisch alle Oracle Produkte; hier beziehen wir uns auf die Updates für die Oracle Database Software.

Weiterlesen

DOAG Konferenz + Ausstellung im November 2023

Vom 21. bis 24. November in Nürnberg im Nürnberg Convention Center (NCC). Wie in den Jahren zuvor waren wir auch dieses Jahr an der DOAG Konferenz + Ausstellung mit einem Vortrag vertreten. Der Vortrag vom 23.11. „Auf zur Oracle Database 23c: New Features, Upgrade-Szenarien, erste Erfahrungen“ von Herrn Lenz steht nun als PDF zum Download bereit

Neues vom SYSAUX-Tablespace Vol. II

Vor einiger Zeit hatten wir ja schon einmal über die Freuden der Objektverwaltung im SYSAUX-Tablespace berichtet (s. HIER).

Heute aus aktuellem Anlass eine kleine Geschichte für all jene, die sich auch darüber wundern, warum Abfragen gegen Data Dictionary Views, hier insbesondere diejenigen, die den Job Scheduler betreffen, immer so lange dauern. Es könnte evtl. an diesem Umstand liegen:

Weiterlesen