CVE-2026-98158

Beschreibung

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: ppp async: Drop the errored frame instead of resetting its headroom ppp receive nonmp frame() prepends a two-byte direction tag before running the pass/active BPF filters: *( be16*)skb push(skb, 2) = htons(PPP FILTER INBOUND TAG); Nichts auf dem Empfangspfad garantiert diese beiden Bytes Headroom. Der Frame-Error-Pfad in ppp asyncs process input packet() setzt eine wiederverwendete skb-Headroom auf Null zurück, während er behauptet, sie in einen frisch zugewiesenen Zustand wiederherzustellen - aber eine neue skb aus dev alloc skb() trägt NET SKB PAD: err: if (skb) { /* make skb appear as freshly assigned */ skb trim(skb, 0); skb reserve(skb, - skb headroom(skb)); } ap->rpkt zeigt immer noch auf diese skb, so dass der nächste Frame ohne Headroom wieder zusammengesetzt wird. Ein Peer, der einen Bad-FCS-Rahmen, gefolgt von einem Anfang ff 03, sendet, hinterlässt dann ein einzelnes Byte Headroom, wenn das Filter-Tag gedrückt wird, das ein Byte unter skb->head landet: skbuff: skb under panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: Kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb panic+0x13e/0x230 Call Trace: skb push+0xbd/0x230 ppp receive nonmp frame+0x48a/0x1d10 ppp input+0x4e9/0x2f80 ppp async process+0x2a/0xe0 tasklet action common+0x20f/0x8a0 handle softirqs+0x Kernel-Panik - nicht synchronisieren: Tödliche Ausnahme beim Interrupt Nullen der Headroom verletzt die NET SKB PAD-Garantie, dass dev alloc skb() den Rest des Empfangspfades gibt. Neben der Filterpanik oben, wenn die CCP-Komprimierung aktiviert ist ppp decompress frame() Hände skb->data - 2 bis ->decompress()/->incomp(), die dann aus dem gleichen Grund außerhalb der Grenzen vor skb->head liest. Anstatt die Headroom wiederherzustellen, lassen Sie den fehlerhaften Frame fallen - wie es ppp synctty bereits auf seinem Fehlerpfad tut - und löschen Sie ap->rpkt, damit der nächste Frame in eine neue skb mit korrekter Headroom wieder zusammengesetzt wird. Dies ist einfacher und behebt sowohl den Filter unter Panic als auch die CCP out-of-bounds gelesen. Die ursprüngliche V1 dieses Patches machte Platz in ppp receive nonmp frame() mit skb cow head(); Eric wies darauf hin, dass die Ursache im Transport der richtige Ansatz ist. Gefunden durch Fuzzing des PPP-Empfangspfades mit einem mutierenden Peer auf einem Pty; es ist ein interessantes (ferngesteuertes) DoS: root konfiguriert PPP, der Peer liefert zwei abstürzende Frames. Der Reproduzierer (repro-ppp-skb.c, unverändert von v1) gerät in etwa einer Sekunde in Panik und kehrt sauber mit dieser Anwendung zurück.

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.