CVE-2026-43292

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