CVE-2026-98151

Beschreibung

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: bpf: Fix REG INVARIANTS VIOLATION auf spekulativer Zeigerarithmetik Nehmen Sie das folgende unprivilegierte Programm als Beispiel: r0 = bpf map lookup elem(...) /* PTR TO MAP VALUE, offset 0 */ ... 14: r0 += r1 /* r1 ist ein begrenzter Skalar */ 15: r9 = r0 Laden Es löst eine Verifier-Warnung aus reg bounds sanity check(): verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffffff} var off=(0x0, 0x0) Was passiert: 1. Verarbeitung insn 14 (r0 += r1) in adjust ptr min max vals(), wird der neue Offset in dst regs var off und 32/64-Bit-Bereichen berechnet. 2. Da Zeigerregister keine 32-Bit-Unterregistergrenzen verfolgen, setzt mark reg32 unbounded() zuerst r32 in den vollen Bereich; r32 wird vom Offset am Ende der Funktion durch reg bounds sync() neu abgeleitet. 3. Auf dem unprivilegierten Pfad wird sanitize ptr alu() aufgerufen und schnappt über sanitize speculative path() -> push stack() den aktuellen Registerzustand und plant die nächste Anweisung (insn 15), die direkt als spekulativer Pfad verifiziert werden soll. 4. Diese Momentaufnahme wird zwischen Schritt 2 und dem endgültigen reg bounds sync() gemacht: an diesem Punkt hält dst regs var off noch den (konst) ursprünglichen Offset, während r32 gerade auf den vollen Bereich ausgeblendet wurde, d.h. die beiden sind nicht synchronisiert. Wenn der spekulative Pfad später insn 15 (r9 = r0) überprüft, erreicht der inkonsistente Zustand reg bounds sanity check() und löst die Warnung aus. var off und der 32-Bit-Bereich müssen immer konsistent sein. Es gibt zwei Möglichkeiten, den Snapshot konsistent zu halten: 1. sync var off und r32 vor dem Snapshot, damit sie übereinstimmen, oder 2. r32 bei seinem ursprünglichen (bereits konsistenten) Wert belassen und erst nach dem Snapshot leeren. Der ganze Sinn von sanitize ptr alu() besteht darin, eine harmlose Maskierungssequenz einzufügen, die den Zugriff unter Spekulationen in Grenzen hält, so dass der Zustand, den sie schnappt, dies treu darstellen sollte. Nehmen Sie Ansatz 2: Bewegen Sie mark reg32 unbounded() nach sanitize ptr alu(), so dass der spekulative Snapshot den ursprünglichen, konsistenten r32 des Zeigers beibehält. Der nicht-spekulative Pfad ist unverändert: r32 wird noch ausgeblendet, bevor der Offset angewendet und durch reg bounds sync() neu abgeleitet wird.

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren: linux linux kernel.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.