Linux Kernel bis 7.2.8/7.3-rc4 kprobes kprobes-optimization wait_for_kprobe_optimizer_locked Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
4.0$0-$5k1.34-

Zusammenfassunginfo

Eine als problematisch eingestufte Schwachstelle wurde in Linux Kernel bis 7.2.8/7.3-rc4 festgestellt. Es geht um die Funktion wait_for_kprobe_optimizer_locked der Datei /proc/sys/debug/kprobes-optimization der Komponente kprobes. Die Veränderung resultiert in Denial of Service. Eine eindeutige Identifikation der Schwachstelle wird mit CVE-2026-98530 vorgenommen. Der Angriff muss lokal angegangen werden. Es gibt keinen verfügbaren Exploit. Die Aktualisierung der betroffenen Komponente wird empfohlen.

Detailsinfo

Es wurde eine Schwachstelle in Linux Kernel bis 7.2.8/7.3-rc4 entdeckt. Sie wurde als problematisch eingestuft. Dabei betrifft es die Funktion wait_for_kprobe_optimizer_locked der Datei /proc/sys/debug/kprobes-optimization der Komponente kprobes. Durch Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-667 vorgenommen. Die Auswirkungen sind bekannt für die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix permanent hang when flushing the kprobe optimizer Writing 0 to /proc/sys/debug/kprobes-optimization while a kprobe is jump-optimized never returns. The writer sleeps in D state forever with kprobe_sysctl_mutex held, so any later read or write of that sysctl hangs as well. For example, with vfs_read+9 as an optimizable address in this build: # cd /sys/kernel/tracing # echo 'p:myprobe vfs_read+9' >> kprobe_events # echo 1 > events/kprobes/myprobe/enable # # wait until /sys/kernel/debug/kprobes/list shows [OPTIMIZED] # echo 0 > /proc/sys/debug/kprobes-optimization INFO: task sh:246 blocked for more than 10 seconds. Call Trace: <TASK> __schedule+0x1176/0x4f70 schedule+0xdc/0x2c0 schedule_timeout+0x17b/0x260 wait_for_completion+0x173/0x3c0 wait_for_kprobe_optimizer_locked+0xbc/0x130 proc_kprobes_optimization_handler+0x156/0x1b0 proc_sys_call_handler+0x324/0x490 vfs_write+0x52d/0xfe0 ksys_write+0xff/0x200 do_syscall_64+0x106/0x630 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ... INFO: task cat:265 is blocked on a mutex likely owned by task sh:246. wait_for_kprobe_optimizer_locked() reinitializes optimizer_completion, asks the optimizer thread to flush and sleeps in wait_for_completion(). The thread drains the (un)optimizing lists, but calls complete() only if completion_done() is true, i.e. if the completion is already done, which never happens while someone waits. disarm_all_kprobes() and kprobe_trace_self_tests_init() wait the same way. Calling complete() unconditionally would not be enough: the waiter drops kprobe_mutex while it sleeps, and nothing else serializes the sysctl handler against the debugfs "enabled" file. A second flusher that still finds the lists non-empty, e.g. because a disabled probe is queued for unoptimizing, reinitializes the completion under the first: sysctl write debugfs "enabled" write unoptimize_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) mutex_unlock(&kprobe_mutex) wait_for_completion(c) disarm_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) // c->wait is reset, the first // waiter is off the queue mutex_unlock(&kprobe_mutex) wait_for_completion(c) kprobe_optimizer() complete(c) // wakes the debugfs writer only where c is &optimizer_completion. Lining up the two writes during an optimizer pass loses the sysctl writer this way. Replace the completion with a counter of optimizer passes, bumped at the end of each pass and signalled with wake_up_var_locked(), both under kprobe_mutex. A flusher samples the count and waits with wait_var_event_mutex(), which drops kprobe_mutex only while sleeping, so a new count means a whole pass ran in the meantime. Nothing is reinitialized, so several flushers can sleep in the wait at once.

Das Advisory findet sich auf git.kernel.org. Die Identifikation der Schwachstelle wird seit dem 25.09.2026 mit CVE-2026-98530 vorgenommen. Das Ausnutzen gilt als leicht. Der Angriff muss lokal erfolgen. Das Ausnutzen erfordert eine erweiterte Authentisierung. Eine Ausnutzung erfordert, dass das Opfer eine spezifische Handlung durchführt. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt.

Ein Aktualisieren auf die Version 7.2.9 oder 7.3-rc5 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches f05a01fc7d4f731b4c100d2aef1e85ad77728862/5bfa9f1a9dcb6ecb607adbc1c0226605c972935b lösen. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 4.2
VulDB Meta Temp Score: 4.0

VulDB Base Score: 4.2
VulDB Temp Score: 4.0
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-667
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 7.2.9/7.3-rc5
Patch: f05a01fc7d4f731b4c100d2aef1e85ad77728862/5bfa9f1a9dcb6ecb607adbc1c0226605c972935b

Timelineinfo

25.09.2026 CVE zugewiesen
18.10.2026 +23 Tage Advisory veröffentlicht
18.10.2026 +0 Tage VulDB Eintrag erstellt
18.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-98530 (🔒)
GCVE (CVE): GCVE-0-2026-98530
GCVE (VulDB): GCVE-100-421803

Eintraginfo

Erstellt: 18.10.2026 17:55
Anpassungen: 18.10.2026 17:55 (60)
Komplett: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

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

◂ ZurückÜbersichtWeiter ▸

Want to know what is going to be exploited?

We predict KEV entries!