Linux Kernel bis 7.1.3 sched/rt Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
7.2$0-$5k2.39

Zusammenfassunginfo

Es wurde eine als kritisch klassifizierte Schwachstelle in Linux Kernel bis 7.1.3 entdeckt. Davon betroffen ist unbekannter Code der Komponente sched/rt. Mittels dem Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Die Verwundbarkeit wird als CVE-2026-64374 geführt. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Es ist kein Exploit verfügbar.

Detailsinfo

In Linux Kernel bis 7.1.3 wurde eine kritische Schwachstelle gefunden. Es geht um eine unbekannte Funktion der Komponente sched/rt. Durch das Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-399. Dies wirkt sich aus auf die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.

Auf git.kernel.org kann das Advisory eingesehen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 19.07.2026 mit CVE-2026-64374 vorgenommen. Das Ausnutzen gilt als leicht. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Um eine Ausnutzung durchzusetzen, muss keine spezifische Authentisierung umgesetzt werden. Nicht vorhanden sind sowohl technische Details als auch ein Exploit zur Schwachstelle. Als Preis für einen Exploit ist zur Zeit ungefähr mit USD $0-$5k zu rechnen (Preisberechnung vom 25.07.2026).

Ein Upgrade auf die Version 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4 oder 7.2-rc1 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches b99f04ae3d200d2f8844aa29145bd18eccbeecde/d8312a56d9a162e3ec76476aa487e7d20bc602e9/44aae426dbfd51286f7eb601cfa14bc32164812a/860aaff72c8446fed5e576249e19952883a18885/89237c8fc15d8016a194076e648ccb57d75e65ae/4bd0da48fbc1dbef6774175129107fbbdd353e26/a18f80bf5359238c4f067d691b96af00286fdd89/dd29c017aed628076e915fe4cdfb5392fd4c5cab beheben.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 7.5
VulDB Meta Temp Score: 7.2

VulDB Base Score: 7.5
VulDB Temp Score: 7.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-399 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert

EPSS Score: 🔒
EPSS Percentile: 🔒

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 5.10.261/5.15.212/6.1.178/6.6.145/6.12.96/6.18.39/7.1.4/7.2-rc1
Patch: b99f04ae3d200d2f8844aa29145bd18eccbeecde/d8312a56d9a162e3ec76476aa487e7d20bc602e9/44aae426dbfd51286f7eb601cfa14bc32164812a/860aaff72c8446fed5e576249e19952883a18885/89237c8fc15d8016a194076e648ccb57d75e65ae/4bd0da48fbc1dbef6774175129107fbbdd353e26/a18f80bf5359238c4f067d691b96af00286fdd89/dd29c017aed628076e915fe4cdfb5392fd4c5cab

Timelineinfo

19.07.2026 CVE zugewiesen
25.07.2026 +6 Tage Advisory veröffentlicht
25.07.2026 +0 Tage VulDB Eintrag erstellt
25.07.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-64374 (🔒)
GCVE (CVE): GCVE-0-2026-64374
GCVE (VulDB): GCVE-100-383170

Eintraginfo

Erstellt: 25.07.2026 17:40
Anpassungen: 25.07.2026 17:40 (58)
Komplett: 🔍
Cache ID: 216::103

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Might our Artificial Intelligence support you?

Check our Alexa App!