Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - bpf告知 memcg 使用 bpf_timer_init() 中的 allow_spinning=false 路徑。目前從 __bpf_async_init() 呼叫 bpf_map_kmalloc_node() 會造成多種鎖定問題請參閱下列堆疊追踪 (針對樣式進行編輯) 範例之一... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) 雙重取得相同 [10.011575] kick_pool rq_lock造成硬鎖定 [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 引發 [10.011597] obj_cgroup_charge_pages MEMCG_MAX 事件 [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 呼叫 bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueuerq_sclockPF 以保留的 2) 執行 enqueuerq_sclockPF [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
    修改 ./tools/sched_ext/scx_flatcg.bpf.c 以在 ops.runnable() 期間呼叫 bpf_timer_init()進而在 bpf-next (b338cf849ec8) 上重現上述情形並稍微入侵 memcg 計量程式碼以產生 bpf_timer_init()呼叫更有可能引發 MEMCG_MAX 事件。我們也遇到過其他類似的變體 (內部和 bpf-next 都有)包括雙重取得 cgroup_file_kn_lock、相同的 worker_pool::lock 等等。根據 Shakeel 的建議在 中使用 __GFP_HIGH 而非 GFP_ATOMIC 來修正此問題。
    __bpf_async_init()因此例如如果 try_charge_memcg() 引發 MEMCG_MAX 事件我們會呼叫
    __memcg_memory_event() 和 @allow_spinning=false 並避免在該處呼叫 cgroup_file_notify()。取決於 mm 修補程式 memcg如果不允許旋轉則跳過 cgroup_file_notify
    https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 方法 s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 方法
    https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/ (CVE-2025-39886)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-39886

critical Nessus Plugin ID 265877

版本 1.1