CVE-2026-64374
Beschreibung
Im Linux-Kernel wurde die folgende Sicherheitsanfälligkeit behoben: sched/rt: Lassen Sie RT PUSH IPI standardmäßig für die nicht PREEMPT RT RT-Migration deaktiviert sein. Wenn eine CPU eine RT-Aufgabe mit hoher Priorität für eine Aufgabe mit niedrigerer Priorität plant, wird geprüft, ob es RT-Aufgaben gibt, die darauf warten, auf einer anderen CPU ausgeführt zu werden, die eine höhere Priorität hat als die Aufgabe, die diese CPU ausführen möchte. Wenn es eine findet, wird es diese Aufgabe an die CPU ziehen und es stattdessen dort laufen lassen. Normalerweise wird dieses Ziehen durch Betrachten der RT-überlasteten Maske (rto) durchgeführt, die alle CPUs in der Scheduler-Domäne mit RT-Tasks enthält, die aufgrund einer RT-Task mit höherer Priorität, die derzeit auf ihrer CPU ausgeführt wird, auf die Ausführung warten. Die CPU, die im Begriff ist, eine Aufgabe mit niedrigerer Priorität zu planen, wird die rq-Sperre der überlasteten CPU greifen und die RT-Task von der Runqueue dieser CPU in die lokale verschieben und die RT-Task mit höherer Priorität planen. Dies führte zu Problemen, wenn viele CPUs gleichzeitig eine Aufgabe mit niedrigerer Priorität planen würden. Sie würden alle versuchen, die gleiche Runqueue-Sperre der CPU mit den überlasteten RT-Aufgaben zu greifen. Nur die erste CPU, die eingestiegen ist, wird diese Aufgabe erhalten. Alle anderen würden warten, bis sie das Runqueue-Schloss haben und sehen, dass es nichts zu ziehen und nichts zu tun gibt. Auf Systemen mit vielen CPUs verursachte dies eine große Latenz (bis zu 500us), die über das hinausgeht, was PREEMPT RT erlauben soll. Die Lösung dafür war die Erstellung einer RT PUSH IPI-Logik. Wenn eine CPU eine Aufgabe ziehen wollte, anstatt die Runqueue-Sperre der überlasteten CPU zu greifen, würde sie damit beginnen, einen IPI an die überlastete CPU zu senden, und dieser IPI-Handler würde die CPU mit der wartenden RT-Task stattdessen einen Push machen lassen. Dann würde dieser Handler einen IPI an die nächste CPU mit überlasteten RT-Aufgaben senden und so weiter. Beachten Sie, nachdem die erste CPU diesen Prozess gestartet hat, wenn eine andere CPU einen Pull durchführen wollte, würde sie sehen, dass der Prozess bereits begonnen hat, und würde nur einen Zähler inkrementieren, um die IPIs wieder fortzusetzen. Der RT PUSH IPI löste das Latenzproblem mit PREEMPT RT, konnte jedoch ein neues Problem mit nicht PREEMPT RT verursachen. Softirqs laufen nämlich in einem Thread-Kontext auf PREEMPT RT, können aber in einem Interrupt-Kontext in Nicht-RT laufen. Wenn ein IPI auf einer CPU landet, die gerade mehrere RT-Tasks geweckt hat und die aktuelle CPU eine Nicht-RT- oder eine RT-Task mit niedriger Priorität ausführt, würde sie anstelle eines Push einfach einen Zeitplan für diese CPU erstellen. Wenn jedoch auch ein Softirq auf dieser CPU ausgeführt wird, muss der Zeitplan warten, bis der Softirq fertig ist. Bis dahin würde die CPU immer noch als überlastet angesehen, da RT-Aufgaben noch darauf warten, darauf ausgeführt zu werden. Eine live-sperre trat auf einer arbeitslast auf, die starken netzwerkverkehr auf einer großen maschine ausführte, wo die softirqs 500us von 750us laufen würden. Und es würde auch RT-Aufgaben wecken, was dazu führt, dass die RT-Pull-Logik ständig ausgeführt wird. Wenn ein Softirq auf einer CPU mit RT-Tasks in die Warteschlange gestellt wurde, aber noch nicht ausgeführt wurde und die anderen CPUs diese CPU als überlastet ansehen würden, würden sie einen IPI an sie senden. Die ..
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.