SecvalisbySYSDEVOPS.EU
Katalog CVE
EnglishPolski

CVE-2025-39886

ŚrednieCVSS 5.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.15%

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

Streszczenie

W jądrze Linux naprawiono podatność w podsystemie BPF, gdzie wywołanie bpf_timer_init() z kontekstu posiadającego już blokadę (np. rq_lock) mogło prowadzić do ponownego zajęcia tej samej blokady i twardego zawieszenia systemu (hardlockup). Problem wynikał z faktu, że ścieżka alokacji pamięci w __bpf_async_init() mogła wywołać zdarzenie MEMCG_MAX i powiadomienie cgroup_file_notify(), które próbowało ponownie zdobyć tę samą blokadę. Poprawka polega na użyciu flagi __GFP_HIGH zamiast GFP_ATOMIC, aby uniknąć wirowania w tej ścieżce.

Ocena ryzyka

Lokalny atakujący lub błędnie napisany program BPF może wywołać twarde zawieszenie jądra (hardlockup), powodując odmowę usługi (DoS) dla całego systemu. Wymaga to jednak możliwości ładowania programów BPF, co zwykle wiąże się z podwyższonymi uprawnieniami.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę (commit opisany w CVE) wraz z zależną łatką mm dotyczącą memcg. Jeśli aktualizacja nie jest możliwa, ogranicz możliwość ładowania programów BPF do zaufanych użytkowników.

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: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/[email protected]/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/[email protected]/ v1 approach: https://lore.kernel.org/bpf/[email protected]/

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