CVE-2026-90589

MEDIUM
Published Nov 9, 2026 Modified Nov 12, 2026 CWE-401

Description

When CONFIG_THREAD_STACK_MEM_MAPPED is enabled, each thread stack is mapped into the kernel virtual address space with a guard page on either side, and the mapping is released during abort cleanup. k_thread_abort_cleanup() in kernel/thread.c has two paths: a deferred one for self-abort, which stashes the mapping in thread_cleanup_stack_addr/thread_cleanup_stack_sz, and an immediate one for a thread aborted by some other thread. The immediate path called do_thread_cleanup(), which ignored its thread argument and only ever unmapped the stashed address — a value populated exclusively by the self-abort path. The mapped stack of a thread aborted by another thread was therefore never unmapped. Every k_thread_abort() of a non-current thread leaks the thread's stack region plus its two guard pages from the kernel virtual address space. Threads that end by returning from their entry function take the working self-abort path, so the leak is specific to explicit cancellation — k_thread_abort(), pthread_cancel(), osThreadTerminate(), or the kernel thread kill shell command. Both k_thread_create() and k_thread_abort() are system calls, so with CONFIG_USERSPACE an unprivileged user-mode thread that has been granted a thread object and a user-capable stack object can drive the leak from user mode, consuming a kernel-side resource it cannot otherwise touch. With CONFIG_KERNEL_VM_SIZE defaulting to 8 MB, a few hundred create/abort cycles exhaust the runtime mapping region. k_mem_map_phys_guard() then returns NULL, and map_thread_stack() guards that only with __ASSERT_NO_MSG(), which is compiled out of production builds; thread creation proceeds to write through a NULL-derived stack base and faults in kernel mode. The impact is a persistent denial of service — a kernel fatal error requiring a reboot — with no memory disclosure or corruption, and it is limited to configurations where memory-mapped thread stacks are enabled (x86 targets with X86_MMU and demand paging disabled, where the option is implied by default).

Is your site exposed to CVE-2026-90589?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

5.5
MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS — Exploit Prediction

0.0010
Probability of exploitation
0.01%
Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

Weakness Type (CWE)

CWE-401 CWE-401

References

Frequently Asked Questions

What is CVE-2026-90589? +
When CONFIG_THREAD_STACK_MEM_MAPPED is enabled, each thread stack is mapped into the kernel virtual address space with a guard page on either side, and the mapping is released during abort cleanup. k_thread_abort_cleanup() in kernel/thread.c has two paths: a deferred one for self-abort, which stashes the mapping in thread_cleanup_stack_addr/thread_cleanup_stack_sz, and an immediate one for a thread aborted by some other thread. The immediate path called do_thread_cleanup(), which ignored its thread argument and only ever unmapped the stashed address — a value populated exclusively by the self-abort path. The mapped stack of a thread aborted by another thread was therefore never unmapped. Every k_thread_abort() of a non-current thread leaks the thread's stack region plus its two guard pages from the kernel virtual address space. Threads that end by returning from their entry function take the working self-abort path, so the leak is specific to explicit cancellation — k_thread_abort(), pthread_cancel(), osThreadTerminate(), or the kernel thread kill shell command. Both k_thread_create() and k_thread_abort() are system calls, so with CONFIG_USERSPACE an unprivileged user-mode thread that has been granted a thread object and a user-capable stack object can drive the leak from user mode, consuming a kernel-side resource it cannot otherwise touch. With CONFIG_KERNEL_VM_SIZE defaulting to 8 MB, a few hundred create/abort cycles exhaust the runtime mapping region. k_mem_map_phys_guard() then returns NULL, and map_thread_stack() guards that only with __ASSERT_NO_MSG(), which is compiled out of production builds; thread creation proceeds to write through a NULL-derived stack base and faults in kernel mode. The impact is a persistent denial of service — a kernel fatal error requiring a reboot — with no memory disclosure or corruption, and it is limited to configurations where memory-mapped thread stacks are enabled (x86 targets with X86_MMU and demand paging disabled, where the option is implied by default). It has a CVSS v3.1 base score of 5.5 (MEDIUM).
How severe is CVE-2026-90589? +
CVE-2026-90589 has a CVSS v3.1 score of 5.5 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance. The EPSS score is 0.0010, placing it in the 0th percentile for exploitation probability.
How do I check if I'm vulnerable to CVE-2026-90589? +
You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

Don't wait for an exploit

Scan your website for vulnerabilities like CVE-2026-90589 — free, no signup required.

Patch and protect

Block known exploits with a web application firewall while you patch, keep your own devices clean, or test the fix on a fresh server.

Compare VPS prices →

Affiliate links: we may earn a commission, your price stays the same.