CVE-2026-43292

In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions. The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section. Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.
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:*:*:*:*:*:*:*:*

History

11 Nov 2026, 20:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/vmalloc: evitar bloqueos de RCU en kasan_release_vmalloc_node Cuando CONFIG_PAGE_OWNER está habilitado, liberar páginas en sombra de KASAN durante la limpieza de vmalloc desencadena un costoso desenrollado de pila que adquiere bloqueos de lectura de RCU. Procesar una ’purge_list’ grande sin reprogramación puede hacer que la tarea retenga la CPU por períodos prolongados (más de 10 segundos), lo que lleva a bloqueos de RCU y posibles condiciones de OOM. El problema se manifiesta en purge_vmap_node() -> kasan_release_vmalloc_node() donde la iteración a través de cientos o miles de entradas de ’vmap_area’ y la liberación de sus páginas en sombra asociadas causa: rcu: INFO: rcu_preempt detectó bloqueos en CPUs/tareas: rcu: Tareas bloqueadas en el ’rcu_node’ de nivel 0 (CPUs 0-1): P6229/1:b..l ... tarea:kworker/0:17 estado:R pila de tarea en ejecución:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Cada llamada a kasan_release_vmalloc() puede liberar muchas páginas, y con el seguimiento de ’page_owner’, cada liberación desencadena save_stack() que realiza el desenrollado de pila bajo bloqueo de lectura de RCU. Sin ceder, esto crea una sección crítica de RCU ilimitada. Añadir llamadas periódicas a cond_resched() dentro del bucle para permitir: - Que los períodos de gracia de RCU se completen - Que otras tareas se ejecuten - Que el planificador anticipe cuando sea necesario La solución utiliza need_resched() para una respuesta inmediata bajo carga, con un recuento de lote de 32 como un límite superior garantizado para prevenir los peores casos de bloqueos incluso bajo carga ligera.

Information

Published : 2026-05-08 14:16

Updated : 2026-11-11 20:10


NVD link : CVE-2026-43292

Mitre link : CVE-2026-43292

CVE.ORG link : CVE-2026-43292


JSON object : View

Products Affected

linux

  • linux_kernel