Linux Kernel: Sicherheitslücke (CVE-2026-98087)

Was ist betroffen, was ist zu tun

Im Linux-Kernel wurde folgende Schwachstelle behoben: sched/rt,dl: Überspringe migrierungsverbotene Aufgaben bei der Auswahl eines Push-Kandidaten Eine migrierungsverbotene RT-Aufgabe kann nicht auf einen anderen Prozessor verschoben werden, aber der Scheduler behält diese Aufgabe weiterhin in der Push-Liste des Prozessors (rq->rt.pushable_tasks) und markiert die Ausführungsreihenfolge als RT-überlastet (rq->rt.overloaded = 1). Der RT-Balancer behandelt diesen Prozessor weiterhin als einen, der eine Aufgabe verschieben muss, und versucht, die Aufgabe zu verschieben, aber der Push kann nie erfolgreich sein.

Aktualisieren Sie Linux Kernel auf Version 6.18.53, Linux Kernel auf Version 7.2.7, Linux Kernel auf Version 7.3.

Betroffen

• Linux Kernel lt 5.11..6.18.53
• Linux Kernel lt 6.19..7.2.7

Behoben in

• Linux Kernel 6.18.53
• Linux Kernel 7.2.7
• Linux Kernel 7.3

Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

Metriken

Erkennungsregeln

Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

Einordnung nach NIS2 und CRA

Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

NIS2

NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

Im Glossar lesen

Behandeln Sie die Schwachstelle im regulären Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2.

CRA

Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

Im Glossar lesen

Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.

ISO/IEC 27001

ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

Im Glossar lesen

Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

Beschreibung

Im Linux-Kernel wurde folgende Schwachstelle behoben: sched/rt,dl: Überspringe migrierungsverbotene Aufgaben bei der Auswahl eines Push-Kandidaten Eine migrierungsverbotene RT-Aufgabe kann nicht auf einen anderen Prozessor verschoben werden, aber der Scheduler behält diese Aufgabe weiterhin in der Push-Liste des Prozessors (rq->rt.pushable_tasks) und markiert die Ausführungsreihenfolge als RT-überlastet (rq->rt.overloaded = 1). Der RT-Balancer behandelt diesen Prozessor weiterhin als einen, der eine Aufgabe verschieben muss, und versucht, die Aufgabe zu verschieben, aber der Push kann nie erfolgreich sein. Wenn der Kopf gepinnt ist, gibt push_rt_task() nicht auf. Es fällt zurück und versucht, rq->curr zu verschieben, indem es den pro-CPU-Stopper verwendet, wie in dem Commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing") hinzugefügt. Der Prozessor verbringt Zehntelsekunden in dieser Wiederholungsschleife. Der Kern ist für Echtzeit-Arbeiten isoliert, aber während der Schleife wird fast die Hälfte seiner Zeit von Push-Versuchen verbraucht, die nie erfolgreich sein können. Eine ftrace-Aufnahme des betroffenen Prozessors, mit sched_switch aktiviert und dem Commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") angewendet, zeigt, wohin die Prozessorzeit gegangen ist. Zwei SCHED_FIFO-Aufgaben mit gleicher Priorität teilten sich den Prozessor, taskA wurde migrierungsverboten und in die Warteschlange gestellt, taskB als rq->curr. In einem 89 ms-Fenster erhielt taskB nur 52 ms Prozessorzeit. Die anderen 37 ms gingen an den Stopp-Thread. Der Scheduler versuchte weiterhin, taskA zu verschieben, den gepinnten Kopf der Push-Liste, fiel zurück und versuchte, taskB stattdessen zu verschieben, und weckte den Stopp-Thread 5204-mal. Jeder dieser Push-Versuche schlug fehl und keine Aufgabe wurde verschoben. taskA blieb ausführbar und in der Warteschlange, und wurde nie ausgeführt. Der Versuch, taskB zu verschieben, schlägt bei einer erneuten Überprüfung fehl. find_lock_lowest_rq() gibt den rq-Lock frei, um den Ziel-rq-Lock zu nehmen, und überprüft erneut mit "task != pick_next_pushable_task(rq)". Die zu verschiebende Aufgabe ist taskB, aber die Auswahl gibt taskA zurück, den Kopf der Push-Liste. taskB ist rq->curr, und set_next_task_rt() entfernt die laufende Aufgabe von dieser Liste, so dass taskB niemals der Kopf sein kann. Die Überprüfung erwartet einen Kandidaten aus der Push-Liste, aber die Fallback-Pushes rq->curr, die niemals auf dieser Liste sind. Daher schlägt die Überprüfung jedes Mal fehl. .--> Push-IPI ankommt | | | v | Kopf der Push-Liste = taskA -> gepinnt, kann nicht verschoben werden | | | v | also versuche, taskB stattdessen zu verschieben -> wecke Migration/N, einen Stopp-Klassen-Thread, so dass er taskB vorwegnimmt | | | v | erneute Überprüfung vergleicht taskB mit dem Kopf der Push-Liste, | der immer noch taskA ist -> aufgeben | | | v | nichts verschoben, taskA immer noch in der Warteschlange, rq immer noch überlastet | | '----------' wiederholt sich alle ~17 us, 5204-mal, für 89 ms Die Schleife kann sich selbst nicht stoppen. Jede Runde lässt die Ausführungsreihenfolge genau so, wie sie war, so dass der nächste Push-IPI dasselbe tut. In der Aufnahme endete sie nur, als taskB von selbst schlief. taskA wurde dann lokal ausgewählt und verließ die Push-Liste. Prozessorzeit pro Aufgabe im Fenster, von sched_switch: taskB 51.95 ms reale Arbeit Migration/N 37.18 ms nichts verschoben taskA 0.00 ms die ganze Zeit in der Warteschlange, nie ausgewählt idle 0.01 ms Zählungen über dasselbe Fenster: 7667 Push-IPIs wurden auf diesem Prozessor behandelt 17481 pick_next_pushable_task() gab taskA zurück, immer noch gepinnt 5204 find_lock_lowest_rq() gab bei der erneuten Überprüfung auf 1 Push, der tatsächlich abgeschlossen wurde 0 Verschiebungen von taskA Die Prozessorzeiten und die Fensterlänge stammen vom Standard-sched_switch-Tracepoint. Die Zählungen erforderten Tracepoints, die im RT-Balancer für diese Untersuchung hinzugefügt wurden. Der Selbst-IPI-Weg wird durch die oben genannte rto_next_cpu()-Behebung geschlossen, und dieser Teil funktioniert. Aber die Ausführungsreihenfolge wird immer noch als überlastet markiert, weil die gepinnte Aufgabe weiterhin als pushbar beworben wird. Andere Prozessoren senden jetzt die Push-IPIs während ihrer eigenen RT-Balancierung, und die gleiche Schleife läuft erneut. Das Schließen des Selbst-IPI-Wegs hat die pinn

Quelle: BSI WID Portal, BSI CSAF, cvelistv5, Microsoft Security Update Guide, NVD (NIST)

Quellen & Referenzen

• git.kernel.orgstable/c/755476d7ba92a1f3fe2a376c515d710bc6baebc3
• git.kernel.orgstable/c/b0c6f947057751ab4d30ccf8095cd19804fb97fa
• git.kernel.orgstable/c/dae5c0292080dd7b9c7d784268dcf443f1f3d15e

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE – Reanalyses, CVSS-Updates, CPE-Diffs.

1. CVE Modified19.10.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

   • Affected: nachher Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98087.json">CVE-2026-98087</a>

2. New CVE Received25.09.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

   • Description: nachher In the Linux kernel, the following vulnerability has been resolved: sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran. Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing. In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA, still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint. The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinn ---truncated---
   • Affected: nachher New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98087.json">CVE-2026-98087</a>
   • Reference: nachher https://git.kernel.org/stable/c/755476d7ba92a1f3fe2a376c515d710bc6baebc3
   • Reference: nachher https://git.kernel.org/stable/c/b0c6f947057751ab4d30ccf8095cd19804fb97fa