FlawOpen

flawopen.com/Teardowns/cve-2025-39682-linux-ktls-zero-length-record-mishandling

● CVE-2025-39682 · CVSS 9.8 · Kritisch
Sicherheitsforschung · FlawOpen

Linux CVE-2025-39682: Leerer Datensatz im kTLS-Empfang

Ein TLS-Nicht-DATA-Datensatz mit Länge null in Linux’ kTLS-Empfangswarteschlange konnte die Datensatztyp-Prüfung pro recvmsg umgehen. Der Fix prüft den verarbeiteten Typ auch dann, wenn null Bytes kopiert wurden. Die Linux-CVSS-Bewertung nennt eine mögliche Offenlegung des Kernel-Heaps an den Userspace, Speicherbeschädigung und entfernte Kernel-Abstürze; dies sind bewertete Folgen und keine Behauptung, dass jedes betroffene System alle Folgen erleidet.

CVSS-VektorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
💡 Einfache Erklärung (ELI5)

Stell dir eine Poststelle vor, die pro Fach nur Briefe einer Kategorie einsortieren darf. Auch ein leerer Umschlag hat eine Kategorie, aber die alte Sortieranlage entschied anhand der gezählten Briefe, ob sie das Fach wechselt. Bei null Briefen ignorierte sie die Kategorie und mischte den nächsten Typ ein. Der Kernel-Fix prüft das Kategorienmerkmal, selbst wenn der Umschlag keine Daten enthält.

Kernkonzepte & Begriffe

kTLS
Kernel TLS: Linux kann TLS-Datensätze für einen verbundenen TCP-Socket im Kernel verarbeiten.
recvmsg()
Socket-Empfangsaufruf, den Anwendung und kTLS-Empfangspfad verwenden.
TLS-Inhaltstyp
Feld zur Klassifizierung eines Datensatzes, etwa Anwendungsdaten oder Steuerdatensatz.
rx_list
Warteschlange ausstehender Empfangsdatensätze für spätere recvmsg-Aufrufe.
CWE-754
Unzureichende Prüfung ungewöhnlicher oder außergewöhnlicher Bedingungen. NVD führt CWE-754 mit der Quelle CISA-ADP auf; der Linux-CVE-Eintrag selbst weist keine CWE zu.

Framework-Zuordnungen

Ursachenanalyse

Der Linux-kTLS-Empfang muss pro recvmsg()-Aufruf zusammenhängende DATA-Datensätze oder genau einen Nicht-DATA-Datensatz zurückgeben. Verarbeitete process_rx_list() einen anfänglichen Nicht-DATA-Datensatz mit Länge null, konnte es den TLS-Typ setzen und zugleich err == 0 zurückgeben. tls_sw_recvmsg() übernahm null in copied und nutzte (copied && control != TLS_RECORD_TYPE_DATA) als Teil der Abbruchbedingung. Da copied null war, wurde der bereits verarbeitete Typ ignoriert und der Pfad fuhr mit folgenden Daten fort. Der Upstream-Fix prüft control direkt: Ist ein Typ gemeldet und nicht DATA, wird gestoppt; null bleibt der Platzhalter für „noch kein Typ gemeldet“. Betroffen sind nur Systeme, auf denen der Linux-Kernel-TLS-Empfang (kTLS) aktiviert und genutzt wird; dies ist kein Fehler in allen TLS-Bibliotheken im Userspace. Der von Linux veröffentlichte CVSS-3.1-Vektor lautet 9,8 Kritisch (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Bewerten Sie die Exposition anhand der tatsächlichen kTLS-Nutzung und des Kernelstands des Anbieters.

Schritt-für-Schritt Angriffsablauf

Schritt 1

kTLS empfängt Datensätze

Eine Anwendung nutzt einen TCP-Socket mit aktiviertem Kernel-TLS-Empfang.

Schritt 2

Ein leerer Nicht-DATA-Datensatz aus der Warteschlange wird verarbeitet

Der Sonderfall tritt auf, wenn der erste Datensatz in rx_list keine Nutzdaten hat. Die Verarbeitung kann einen Typ melden und null kopierte Bytes zurückgeben.

Schritt 3

Die alte Bedingung orientiert sich an kopierten Bytes

Weil copied null ist, prüft die alte Bedingung nicht, ob der verarbeitete Typ Nicht-DATA war.

Schritt 4

Die Empfangsschleife überschreitet die Typgrenze

Folgende Daten können im selben recvmsg-Aufruf verarbeitet werden, entgegen der Ein-Typ-Regel. Die Linux-CVSS-Bewertung nennt eine mögliche Offenlegung des Kernel-Heaps an den Userspace, Speicherbeschädigung und entfernte Kernel-Abstürze; dies sind bewertete Folgen und keine Behauptung, dass jedes betroffene System alle Folgen erleidet.

Schritt 5

Der Fix prüft den semantischen Marker

Die korrigierte Bedingung stoppt bei einem gesetzten Nicht-DATA-Typ in control, unabhängig von der Bytezahl.

Quellcode: Verwundbar vs. Sicher

Auszug aus net/tls/tls_sw.c, keine vollständige Funktion. Der Upstream-Fix verwendet für die Abbruchbedingung den gemeldeten Inhaltstyp statt der kopierten Bytezahl. control == 0 bedeutet, dass kein Typ gemeldet wurde; ein gesetzter Nicht-DATA-Typ beendet diesen recvmsg-Aufruf. Dies ist die exakte Logikänderung des Upstream-Patches.

Quelltextauszug: net/tls/tls_sw.c — Funktion tls_sw_recvmsg

VERWUNDBARE IMPLEMENTIERUNG
copied = err;
if (len <= copied ||
    (copied && control != TLS_RECORD_TYPE_DATA) || rx_more)
    goto end;
GEHÄRTETER SICHERHEITS-PATCH
copied = err;
if (len <= copied || rx_more ||
    (control && control != TLS_RECORD_TYPE_DATA))
    goto end;

Checkliste für Engineering & Systemsicherheit

Quellen