CVE-2026-64352
Beschreibung
Im Linux-Kernel wurde die folgende Sicherheitsanfälligkeit behoben: bpf: Erlauben Sie LPM-Kartenzugriff von schlafbaren BPF-Programmen trie lookup elem() kommentiert seine rcu dereference check() geht nur mit rcu read lock bh held(). Da rcu dereference check(p, c) auf "c || rcu read lock held()" aufgelöst wird, gilt dies für XDP/NAPI- und klassische RCU-Lesegeräte, schlägt jedoch bei schlafbaren BPF-Programmen fehl, die über bpf prog enter sleepable() eingegeben werden und nur rcu read lock trace() halten. trie update elem() und trie delete elem() haben das gleiche Problem in einer anderen Form: Sie gehen die Trie mit plain rcu dereference(), was rcu read lock held() bedingungslos behauptet. Beide sind von schlafbaren BPF-Programmen über die bpf map update elem / bpf map delete elem-Helfer und über den Syscall-Pfad unter classic rcu read lock() erreichbar. In den Schreibpfaden ist der Trie tatsächlich durch Trie->Lock geschützt (ein rqspinlock, der über den Spaziergang genommen wurde); wir haben uns nie auf die RCU-Leseseite verlassen, um Knoten dort am Leben zu halten. Ein schlafbarer LSM-Hook, der am Ende einen LPM-Trie berührt, löst daher Lockdep bei Debug-Kerneln aus: =============================================WARNUNG: verdächtige RCU-Nutzung 7.1.0-... Befleckt: G E ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Dies ist Lockdep-only - keine UAF, da Tasks Trace RCU gegen den Reclaim-Pfad des Tries serialisiert - aber es spammt die Konsole einmal pro eindeutiger Callite auf jedem Debug-Kernel, der einen schlafbaren BPF LSM ausführt, der einen LPM-Trie berührt, was immer häufiger vorkommt. Wechseln Sie für den Suchpfad die Anmerkung rcu dereference check() von rcu read lock bh held() zu bpf rcu lock held(), die alle drei Kontexte (classic, BH, Tasks Trace) akzeptiert. Andere Kartentypen folgen bereits dieser Konvention. Beschreiben Sie für trie update elem() und trie delete elem() die Walks als rcu dereference protected(*p, 1) - übereinstimmend trie free() in derselben Datei - da trie->lock über den Walk gehalten wird. rqspinlock hat keine lockdep map, daher degeneriert das Prädikat zu '1' anstatt lockdep is held(&trie->lock); der Schutz ist real, aber nicht maschinenüberprüfbar. trie get next key() verwendet auch bare rcu dereference(), ist aber nur über den BPF-Syscall erreichbar, der vor dem Versand die klassische rcu read lock() enthält, so dass sie unberührt bleibt.
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.
- Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.