CVE-2025-39886
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-23

Last updated on: 2025-12-12

Assigner: kernel.org

Description
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]/
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-23
Last Modified
2025-12-12
Generated
2026-05-07
AI Q&A
2025-09-23
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39886
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15 (inc) to 6.6.107 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.48 (exc)
linux linux_kernel From 6.13 (inc) to 6.16.8 (exc)
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's BPF subsystem where calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues, such as double-acquiring the same lock (rq_lock), leading to a hardlockup. The problem arises because memcg (memory control group) accounting raises an MEMCG_MAX event during this process, which triggers cgroup_file_notify() while spinning is not allowed, causing deadlocks. The fix involves changing the allocation flags to use __GFP_HIGH instead of GFP_ATOMIC to prevent spinning and avoid calling cgroup_file_notify() in this context.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to deadlock (hardlockup) due to locking issues in the BPF subsystem when certain memory control group events occur. This can lead to system instability or crashes, impacting the availability and reliability of systems running vulnerable kernel versions.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by updating the Linux kernel to include the fix that changes __bpf_async_init() to use __GFP_HIGH instead of GFP_ATOMIC, which prevents locking issues related to memcg accounting and BPF timer initialization. Therefore, the immediate mitigation step is to apply the kernel patch or update to a kernel version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart