Katalog CVE

CVE-2026-98789

Niskie ryzyko· EPSS 4%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.16%

Percentyl 4 - wyżej niż 4% wszystkich znanych CVE

Streszczenie

W jądrze Linux w podsystemie BPF występuje błąd w mechanizmie zwalniania pamięci przez RCU tasks trace. Obiekty dodane do free_by_rcu_ttrace w trakcie trwania okresu karencji RCU mogą pozostać tam na stałe, ponieważ flaga call_rcu_ttrace_in_progress jest czyszczona zbyt wcześnie, a liczba takich obiektów nie jest ograniczona.

Ocena ryzyka

Nieograniczony wyciek pamięci w podsystemie BPF może prowadzić do wyczerpania zasobów i destabilizacji systemu, szczególnie na maszynach intensywnie korzystających z map BPF.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę wprowadzającą trójstanową flagę call_rcu_ttrace_in_progress i poprawne kolejkowanie __free_rcu().

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix objects stuck in free_by_rcu_ttrace do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded. Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero. Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu() before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one free_mem_alloc() per GP and kworkers pile up.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS