{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-95108",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T17:05:59.302618Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T17:06:10.079Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "ThreadX",
          "product": "Eclipse ThreadX",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThanOrEqual": "6.5.1.202602a",
              "status": "affected",
              "version": "6.0.1",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.5.2.202603"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "fdesbiens"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eOne logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\u003c/p\u003e\u003cp\u003eThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \u2014 every state transition valid, every service returning `TX_SUCCESS` \u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\u003c/p\u003e\u003cp\u003eVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.\u003c/p\u003e"
            }
          ],
          "value": "One logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\n\n\n\nThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \u2014 every state transition valid, every service returning `TX_SUCCESS` \u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\n\n\n\nVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-772",
              "description": "CWE-772 Missing Release of Resource after Effective Lifetime",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T15:19:16.940Z",
        "orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
        "shortName": "eclipse"
      },
      "references": [
        {
          "url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-9hhf-6357-hpgq"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Deleting a user-mode module thread leaks its privileged kernel stack",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
    "assignerShortName": "eclipse",
    "cveId": "CVE-2026-95108",
    "datePublished": "2026-10-20T15:19:16.940Z",
    "dateReserved": "2026-09-23T13:42:24.310Z",
    "dateUpdated": "2026-10-20T17:06:10.079Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-95108\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-20T17:05:59.302618Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-20T17:06:06.233Z\"}}], \"cna\": {\"title\": \"Deleting a user-mode module thread leaks its privileged kernel stack\", \"source\": {\"discovery\": \"UNKNOWN\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"fdesbiens\"}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 6.8, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N\", \"exploitMaturity\": \"NOT_DEFINED\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"HIGH\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"NONE\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"vendor\": \"Eclipse Foundation\", \"product\": \"Eclipse ThreadX\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.0.1\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.5.1.202602a\"}, {\"status\": \"unaffected\", \"version\": \"6.5.2.202603\"}], \"packageName\": \"ThreadX\", \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-9hhf-6357-hpgq\"}], \"x_generator\": {\"engine\": \"Vulnogram 1.0.5\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"One logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\\n\\n\\n\\nThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \\u2014 every state transition valid, every service returning `TX_SUCCESS` \\u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\\n\\n\\n\\nVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eOne logical thread of a user-mode ThreadX module costs the Module Manager\u0027s shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread\u0027s system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module\u0027s allocation list.\u003c/p\u003e\u003cp\u003eThe Module Manager\u0027s thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop \\u2014 every state transition valid, every service returning `TX_SUCCESS` \\u2014 removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.\u003c/p\u003e\u003cp\u003eVulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.\u003c/p\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-400\", \"description\": \"CWE-400 Uncontrolled Resource Consumption\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-772\", \"description\": \"CWE-772 Missing Release of Resource after Effective Lifetime\"}]}], \"providerMetadata\": {\"orgId\": \"e51fbebd-6053-4e49-959f-1b94eeb69a2c\", \"shortName\": \"eclipse\", \"dateUpdated\": \"2026-10-20T15:19:16.940Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-95108\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-20T17:06:10.079Z\", \"dateReserved\": \"2026-09-23T13:42:24.310Z\", \"assignerOrgId\": \"e51fbebd-6053-4e49-959f-1b94eeb69a2c\", \"datePublished\": \"2026-10-20T15:19:16.940Z\", \"assignerShortName\": \"eclipse\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}