Allocation of Resources Without Limits or Throttling The advisory has been revoked - it doesn't affect any version of package perf6.18-debuginfo (opens in a new tab)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about Allocation of Resources Without Limits or Throttling vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-AMZN2023-PERF618DEBUGINFO-16741226
- published18 May 2026
- disclosed8 May 2026
Introduced: 8 May 2026
NewCVE-2026-43292 (opens in a new tab)Amendment
The Amazon-Linux security team deemed this advisory irrelevant for Amazon-Linux:2023.
NVD Description
Note: Versions mentioned in the description apply only to the upstream perf6.18-debuginfo package and not the perf6.18-debuginfo package as distributed by Amazon-Linux.
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.
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43292
- https://git.kernel.org/stable/c/1afe45f89d54b7183768ebbbbf14238ec187ab5c
- https://git.kernel.org/stable/c/2efa9c02c9b4c0d6866aa445f11056809b25ca28
- https://git.kernel.org/stable/c/5747435e0fd474c24530ef1a6822f47e7d264b27
- https://git.kernel.org/stable/c/b351fbe71091f7c8676c8ba597653d08b6719447