Odebrany

CVE-2026-98530

opublikowano: 18.10.2026, 18:17

modyfikacja: 19.10.2026, 12:19

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

kprobes: Naprawiono trwałe zawieszenie podczas płukania optymalizatora kprobe

Zapisanie 0 do /proc/sys/debug/kprobes-optimization, gdy kprobe jest
zoptymalizowane pod kątem skoków nigdy nie powraca. Pisarz śpi w stanie D na zawsze
kprobe_sysctl_mutex wstrzymany, więc każdy późniejszy odczyt lub zapis tego sysctl
też wisi. Na przykład z vfs_read+9 jako adresem możliwym do optymalizacji
w tej kompilacji:

# cd /sys/kernel/tracing
# echo 'p:myprobe vfs_read+9' >> kprobe_events
# echo 1 > zdarzenia/kprobes/myprobe/enable
# # poczekaj, aż /sys/kernel/debug/kprobes/list pokaże [OPTYMALIZOWANY]
# echo 0 > /proc/sys/debug/kprobes-optimization

INFO: zadanie sh:246 zablokowane na dłużej niż 10 sekund.
Zadzwoń do śledzenia:
<ZADANIE>
__harmonogram+0x1176/0x4f70
harmonogram+0xdc/0x2c0
harmonogram_limitu czasu+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
wpis_SYSCALL_64_after_hwframe+0x77/0x7f
</ZADANIE>
...
INFO: zadanie cat:265 jest zablokowane na mutexie, którego prawdopodobnie właścicielem jest zadanie sh:246.

wait_for_kprobe_optimizer_locked() ponownie inicjuje uzupełnienie_optymalizatora,
prosi wątek optymalizatora o opróżnienie i zasypia w funkcji wait_for_completion().
Wątek opróżnia (nie)optymalizujące listy, ale wywołuje tylko funkcję Complete().
jeśli kompletacja_done() ma wartość true, tj. jeśli dokończenie zostało już wykonane,
co nigdy nie zdarza się, gdy ktoś czeka. disarm_all_kprobes() i
kprobe_trace_self_tests_init() poczekaj w ten sam sposób.

Bezwarunkowe wywołanie funkcji Complete() nie wystarczy: kelner
upuszcza kprobe_mutex podczas snu i nic innego nie serializuje
sysctl względem pliku „włączonego” debugfs. Drugi spłukiwacz
to nadal stwierdza, że listy nie są puste, np. ponieważ sonda jest wyłączona
w kolejce do niezoptymalizowania, ponownie inicjuje zakończenie w ramach pierwszego:

sysctl zapis debugfs „włączony” zapis
unoptimize_all_kprobes()
wait_for_kprobe_optimizer_locked()
init_completion(c)
mutex_unlock(&kprobe_mutex)
czekaj_na_ukończenie(c)
rozbroić_all_kprobes()
wait_for_kprobe_optimizer_locked()
init_completion(c)
// c->wait zostaje zresetowane, jako pierwsze
// kelner jest poza kolejką
mutex_unlock(&kprobe_mutex)
czekaj_na_ukończenie(c)
kprobe_optimizer()
kompletny(c)
// budzi tylko moduł zapisujący debugfs

gdzie c oznacza &optimizer_completion. Ustawianie w kolejce dwóch zapisów podczas
Optymalizator traci w ten sposób moduł zapisujący sysctl.

Zastąp uzupełnienie licznikiem przebiegów optymalizatora, uderzonym w
koniec każdego przebiegu i sygnalizowane za pomocą wake_up_var_locked(), oba poniżej
kprobe_mutex. Spłukiwacz pobiera próbkę i czeka
wait_var_event_mutex(), która upuszcza kprobe_mutex tylko podczas snu, więc
nowy licznik oznacza, że w międzyczasie przebiegł cały przebieg. Nic nie jest
ponownie zainicjowany, więc kilka spłukiwaczy może jednocześnie czekać.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve