Odebrany

CVE-2026-98644

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ę:

bpf: Unikaj miękkiego blokowania w __htab_map_lookup_and_delete_batch()

__htab_map_lookup_and_delete_batch() nie ma punktu zmiany harmonogramu. The
liczba partii ogranicza liczbę kopiowanych wpisów, a nie liczbę
odwiedzane są wiadra, więc jedno wywołanie BPF_MAP_LOOKUP_BATCH może obejść
mapa od końca do końca. Gorsza jest szybka ścieżka z pustym wiadro: pozostaje w środku
pojedyncza sekcja rcu_read_lock() / bpf_disable_instrumentation() dla
dowolny ciąg kolejnych pustych wiader.

Daje to radę na małych mapach, ale rozpada się w skali. Na
Host arm64 ze 144 procesorami i jądrem CONFIG_PREEMPT_NONE, okresowo
Wywołania BPF_MAP_LOOKUP_BATCH względem mapy skrótu LRU z 16 777 216
zasobniki utrzymywały procesor w operacji wsadowej przez ponad 77 sekund i zostały uruchomione
miękki strażnik blokujący.

Zatwierdzenie 75134f16e7dd („bpf: Dodaj punkty harmonogramu w operacjach wsadowych”) naprawiło to
ten sam problem w ogólnych operacjach wsadowych, ale nie w tej ścieżce natywnej dla htab,
którego każdy wariant mapy mieszającej opartej na htab używa do wyszukiwania[_and_delete]
operacje wsadowe.

Dokończ tę naprawę tutaj. Opuść sekcję krytyczną po 64 kolejnych
puste wiadra, wywołaj funkcję cond_resched_tasks_rcu_qs() i wznów zapisane
kursor wiadra. W tym momencie nie są utrzymywane żadne blokady, a wznowienie od
kursor jest już zachowaniem funkcji dla niepustych zasobników. Dodaj
to samo wywołanie pętli per-bucket po copy_to_user(), gdzie każda blokada
został upuszczony. cond_resched_rcu() tutaj nie wystarczy: spanie z
bpf_prog_active podwyższone sprawia, że programy śledzące na tym procesorze działają w trybie cichym
pomiń ich wezwania.

Zwykła funkcja cond_resched() też nie wystarczy. W przypadku PREEMPT nie jest to możliwe
i PREEMPT_LAZY, jedyne modele arm64 i x86 oferowane od tego czasu
zatwierdzić 7dadeaa6e851 („sched: Dalsze ograniczenie trybów wywłaszczania”).
W żadnym modelu nie jest to również stan spoczynku modułu RCU zadań:
zmiana terminu liczy się jako wywłaszczenie. Zadanie chodzenia pozostaje zadaniem powstrzymującym i
zatrzymuje każdą funkcję wywołującą synchronize_rcu_tasks(), ftrace i trampolinę BPF
łącznie z porzuceniem, aż do powrotu wywołania systemowego [1].
Cond_resched_tasks_rcu_qs() jest do tego zwykle stosowanym narzędziem [2]. Raportuje
stan spoczynku przy każdym uzysku i nadal zmienia harmonogram
cond_resched() działa na jądrach PREEMPT_NONE i PREEMPT_VOLUNTARY.

In the Linux kernel, the following vulnerability has been resolved:

bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()

__htab_map_lookup_and_delete_batch() has no rescheduling point. The
batch count bounds how many entries are copied out, not how many
buckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the
map end to end. The empty-bucket fast path is worse: it stays inside
a single rcu_read_lock() / bpf_disable_instrumentation() section for
any run of consecutive empty buckets.

That holds up on small maps, but it falls apart at scale. On a
144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic
BPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216
buckets held a CPU inside the batch op for 77+ seconds and triggered
the soft lockup watchdog.

Commit 75134f16e7dd ("bpf: Add schedule points in batch ops") fixed this
same problem in the generic batch ops, but not in this htab-native path,
which every htab-based hash map variant uses for its lookup[_and_delete]
batch ops.

Complete that fix here. Leave the critical section after 64 consecutive
empty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved
bucket cursor. No locks are held at that point, and resuming from the
cursor is already the function's behavior for non-empty buckets. Add the
same call to the per-bucket loop after copy_to_user(), where every lock
has been dropped. cond_resched_rcu() is not enough here: sleeping with
bpf_prog_active elevated makes tracing programs on that CPU silently
skip their invocations.

Plain cond_resched() is not enough either. It is a no-op under PREEMPT
and PREEMPT_LAZY, the only models arm64 and x86 have offered since
commit 7dadeaa6e851 ("sched: Further restrict the preemption modes").
It is also never a Tasks RCU quiescent state, in any model: the
reschedule counts as a preemption. The walking task stays a holdout and
stalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline
teardown included, until the syscall returns [1].
cond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports
the quiescent state at each yield and still reschedules as
cond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels.

>_ 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