CVE-2026-90589 (GCVE-0-2026-90589)

Vulnerability from cvelistv5 – Published: 2026-11-09 22:04 – Updated: 2026-11-09 22:04
VLAI
Title
Memory-mapped thread stack is never unmapped when a thread is aborted by another thread, exhausting kernel virtual address space
Summary
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).
CWE
Assigner
zephyr CNA
Impacted products
Vendor Product Version
zephyrproject zephyr Affected: 3.7.0 , < 4.3.2 (semver)
Affected: 4.4.0 , < 4.5.0 (semver)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
          "defaultStatus": "unaffected",
          "packageName": "zephyr",
          "product": "zephyr",
          "programFiles": [
            "kernel/thread.c"
          ],
          "programRoutines": [
            {
              "name": "do_thread_cleanup"
            },
            {
              "name": "k_thread_abort_cleanup"
            }
          ],
          "vendor": "zephyrproject",
          "versions": [
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "3.7.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.5.0",
              "status": "affected",
              "version": "4.4.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \u2014 a value populated exclusively by the self-abort path. The mapped stack of a thread aborted by another thread was therefore never unmapped.\n\nEvery k_thread_abort() of a non-current thread leaks the thread\u0027s 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 \u2014 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.\n\nWith 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 \u2014 a kernel fatal error requiring a reboot \u2014 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)."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 5.5,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-401",
              "description": "dos",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-09T22:04:01.652Z",
        "orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
        "shortName": "zephyr"
      },
      "references": [
        {
          "name": "Fix commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/zephyrproject-rtos/zephyr/commit/d9ec92ccb1d91f4ea5b15271d30169d5b27ba667"
        },
        {
          "name": "GHSA-xj93-xhq8-g5p4",
          "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xj93-xhq8-g5p4"
        }
      ],
      "title": "Memory-mapped thread stack is never unmapped when a thread is aborted by another thread, exhausting kernel virtual address space",
      "x_generator": {
        "engine": "cvelib 1.8.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
    "assignerShortName": "zephyr",
    "cveId": "CVE-2026-90589",
    "datePublished": "2026-11-09T22:04:01.652Z",
    "dateReserved": "2026-09-12T18:04:43.338Z",
    "dateUpdated": "2026-11-09T22:04:01.652Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.