CVE-2026-43292
Received Received - Intake
RCU Stall in Linux Kernel Due to KASAN vmalloc Cleanup

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :

This vulnerability can cause the system to experience RCU stalls, where CPUs or tasks are blocked for extended periods. This can lead to degraded system responsiveness and performance.

In severe cases, the prolonged CPU hold can cause out-of-memory (OOM) conditions, potentially leading to system instability or crashes.


Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's memory management subsystem, specifically in the vmalloc area when CONFIG_PAGE_OWNER is enabled. During the cleanup of vmalloc areas, freeing KASAN shadow pages triggers expensive stack unwinding operations that acquire RCU (Read-Copy-Update) read locks.

When processing a large list of memory areas (purge_list) without rescheduling, the task can hold the CPU for extended periods (over 10 seconds), causing RCU stalls and potentially leading to out-of-memory (OOM) conditions.

The root cause is that each freed page triggers a stack unwinding operation under an RCU read lock, creating an unbounded RCU critical section. The fix involves adding periodic rescheduling points (cond_resched calls) within the loop to allow RCU grace periods to complete, other tasks to run, and the scheduler to preempt when needed.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as RCU stalls and potential out-of-memory (OOM) conditions during vmalloc cleanup when CONFIG_PAGE_OWNER is enabled.

You can detect the issue by monitoring kernel logs for messages indicating RCU stalls, such as lines containing "rcu_preempt detected stalls on CPUs/tasks" or tasks blocked on rcu_node.

Example kernel log messages to look for include:

  • rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
  • rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): ...
  • task stack traces referencing kasan_release_vmalloc_node and purge_vmap_node in mm/vmalloc.c

To check kernel logs for these messages, you can use commands like:

  • dmesg | grep -i rcu
  • journalctl -k | grep -i rcu
  • grep -i 'kasan_release_vmalloc_node' /var/log/kern.log

Monitoring CPU usage for long-running tasks related to vmalloc cleanup and checking for OOM events may also help detect the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is caused by the lack of rescheduling during freeing of KASAN shadow pages, leading to long RCU critical sections and stalls.

Immediate mitigation steps include:

  • Apply the patch that adds periodic cond_resched() calls within the loop freeing shadow pages to allow RCU grace periods to complete and scheduler preemption.
  • Ensure your Linux kernel is updated to a version that includes the fix for this issue (post 2026-05-08).
  • If updating immediately is not possible, consider disabling CONFIG_PAGE_OWNER temporarily to avoid triggering the expensive stack unwinding during vmalloc cleanup.

These steps help prevent long CPU holds and RCU stalls caused by the vulnerability.


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