CVE-2025-39886

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/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*

History

30 Oct 2026, 13:18

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/3e42431a705be8417ac5b696daa1dd43b3d27169 -

19 Oct 2026, 21:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bpf: Indicar a memcg que use la ruta allow_spinning=false en bpf_timer_init() Actualmente, llamar a bpf_map_kmalloc_node() desde __bpf_async_init() puede causar varios problemas de bloqueo; ver el siguiente rastreo de pila (editado por estilo) como un ejemplo: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) adquiriendo dos veces el mismo [10.011575] kick_pool rq_lock, causando un bloqueo total (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) la contabilidad de memcg eleva un [10.011597] obj_cgroup_charge_pages evento 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 llama a bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF se ejecuta con rq_lock retenido [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) toma rq_lock ... Lo anterior fue reproducido en bpf-next (b338cf849ec8) modificando ./tools/sched_ext/scx_flatcg.bpf.c para llamar a bpf_timer_init() durante ops.runnable(), y modificando un poco el código de contabilidad de memcg para hacer que una llamada a bpf_timer_init() sea más propensa a elevar un evento MEMCG_MAX. También nos hemos encontrado con otras variantes similares (tanto internamente como en bpf-next), incluyendo la doble adquisición de cgroup_file_kn_lock, el mismo worker_pool::lock, etc. Como sugirió Shakeel, solucionar esto usando __GFP_HIGH en lugar de GFP_ATOMIC en __bpf_async_init(), de modo que, por ejemplo, si try_charge_memcg() eleva un evento MEMCG_MAX, llamamos a __memcg_memory_event() con @allow_spinning=false y evitamos llamar a cgroup_file_notify() allí. Depende del parche mm 'memcg: omitir cgroup_file_notify si no se permite el spinning': https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ Enfoque v0 s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ Enfoque v1: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/

Information

Published : 2025-09-23 06:15

Updated : 2026-10-30 13:18


NVD link : CVE-2025-39886

Mitre link : CVE-2025-39886

CVE.ORG link : CVE-2025-39886


JSON object : View

Products Affected

linux

  • linux_kernel