Vulnerability-Lookup

GHSA-Q6XR-Q445-2XXH

Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-24 18:30

Details

In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix WARN_ON in tracing_buffers_mmap_close

When a process forks, the child process copies the parent's VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON.

Normally, this isn't an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork.

Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA's open callback.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-23380"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T11:16:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix WARN_ON in tracing_buffers_mmap_close\n\nWhen a process forks, the child process copies the parent\u0027s VMAs but the\nuser_mapped reference count is not incremented. As a result, when both the\nparent and child processes exit, tracing_buffers_mmap_close() is called\ntwice. On the second call, user_mapped is already 0, causing the function to\nreturn -ENODEV and triggering a WARN_ON.\n\nNormally, this isn\u0027t an issue as the memory is mapped with VM_DONTCOPY set.\nBut this is only a hint, and the application can call\nmadvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the\napplication does that, it can trigger this issue on fork.\n\nFix it by incrementing the user_mapped reference count without re-mapping\nthe pages in the VMA\u0027s open callback.",
  "id": "GHSA-q6xr-q445-2xxh",
  "modified": "2026-04-24T18:30:41Z",
  "published": "2026-03-25T12:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23380"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91f3e8d84c89918769e71393f839c9fefadc2580"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0f269ba6fefe9e3cb9feedcf78fcd0b633800c0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cdd96641b64297a2db42676f051362b76280a58b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e39bb9e02b68942f8e9359d2a3efe7d37ae6be0e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q778-7MC2-5QMC

Vulnerability from github – Published: 2022-03-24 00:00 – Updated: 2022-03-30 00:01

Details

Versions affected: BIND 9.18.0 When a vulnerable version of named receives a series of specific queries, the named process will eventually terminate due to a failed assertion check.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-0635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-23T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "Versions affected: BIND 9.18.0 When a vulnerable version of named receives a series of specific queries, the named process will eventually terminate due to a failed assertion check.",
  "id": "GHSA-q778-7mc2-5qmc",
  "modified": "2022-03-30T00:01:10Z",
  "published": "2022-03-24T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0635"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/v1/docs/cve-2022-0635"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220408-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q858-Q2J2-9JG4

Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36

Details

named contains a feature which allows operators to issue commands to a running server by communicating with the server process over a control channel, using a utility program such as rndc. A regression introduced in a recent feature change has created a situation under which some versions of named can be caused to exit with a REQUIRE assertion failure if they are sent a null command string. Affects BIND 9.9.9->9.9.9-P7, 9.9.10b1->9.9.10rc2, 9.10.4->9.10.4-P7, 9.10.5b1->9.10.5rc2, 9.11.0->9.11.0-P4, 9.11.1b1->9.11.1rc2, 9.9.9-S1->9.9.9-S9.

Severity

5.3 (Medium)


                  
                    CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-3138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-16T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "named contains a feature which allows operators to issue commands to a running server by communicating with the server process over a control channel, using a utility program such as rndc. A regression introduced in a recent feature change has created a situation under which some versions of named can be caused to exit with a REQUIRE assertion failure if they are sent a null command string. Affects BIND 9.9.9-\u003e9.9.9-P7, 9.9.10b1-\u003e9.9.10rc2, 9.10.4-\u003e9.10.4-P7, 9.10.5b1-\u003e9.10.5rc2, 9.11.0-\u003e9.11.0-P4, 9.11.1b1-\u003e9.11.1rc2, 9.9.9-S1-\u003e9.9.9-S9.",
  "id": "GHSA-q858-q2j2-9jg4",
  "modified": "2022-05-13T01:36:47Z",
  "published": "2022-05-13T01:36:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3138"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/aa-01471"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201708-01"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180802-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2017/dsa-3854"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97657"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038260"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q8GQ-377P-JQ3R

Vulnerability from github – Published: 2026-06-16 17:34 – Updated: 2026-06-16 17:34

Summary

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

Details

Summary

An assert-based security check in vLLM's activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (python -O or PYTHONOPTIMIZE=1).

Details

vLLM uses an assert statement at vllm/model_executor/layers/pooler/activations.py:48 as its sole security control to restrict which activation functions can be loaded from a HuggingFace model's config.json:

# vllm/model_executor/layers/pooler/activations.py:35-53
function_name: str | None = None
if (
    hasattr(config, "sentence_transformers")
    and "activation_fn" in config.sentence_transformers
):
    function_name = config.sentence_transformers["activation_fn"]
elif (
    hasattr(config, "sbert_ce_default_activation_function")
    and config.sbert_ce_default_activation_function is not None
):
    function_name = config.sbert_ce_default_activation_function

if function_name is not None:
    assert function_name.startswith("torch.nn.modules."), (
        "Loading of activation functions is restricted to "
        "torch.nn.modules for security reasons"
    )
    fn = resolve_obj_by_qualname(function_name)()

Python's assert statements are stripped at compile time when running in optimized mode (python -O or PYTHONOPTIMIZE=1). When the assert is absent, the attacker-controlled function_name from the model's config.json is passed directly to resolve_obj_by_qualname() — an unrestricted import gadget:

def resolve_obj_by_qualname(qualname: str) -> Any:
    module_name, obj_name = qualname.rsplit(".", 1)
    module = importlib.import_module(module_name)
    return getattr(module, obj_name)

This is the same vulnerability class as CVE-2017-1000433 (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).

Attacker-controlled input sources: - config.sentence_transformers["activation_fn"] (line 40) - config.sbert_ce_default_activation_function (line 45)

Affected call sites — get_act_fn() is called via resolve_classifier_act_fn() from: - vllm/model_executor/layers/pooler/seqwise/poolers.py:122 — SequencePooler - vllm/model_executor/layers/pooler/tokwise/poolers.py:130 — TokenPooler

Broader systemic risk: resolve_obj_by_qualname is called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.

Suggested fix: Replace the assert with an explicit conditional raise:

if not function_name.startswith("torch.nn.modules."):
    raise ValueError(
        "Loading of activation functions is restricted to "
        "torch.nn.modules for security reasons"
    )

Impact

Arbitrary code execution. A malicious model author publishes a HuggingFace model with a crafted config.json. When a victim loads this model with vLLM running under python -O or PYTHONOPTIMIZE=1, arbitrary code executes during model initialization with the privileges of the vLLM process.

The attack requires: 1. Victim loads a malicious model from HuggingFace (user interaction) 2. vLLM runs under python -O or PYTHONOPTIMIZE=1 (documented in production use) 3. Model uses a cross-encoder architecture (e.g. BERT or RoBERTa with sequence classification)

Coordinated disclosure note: This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM's stated preferred disclosure channel per SECURITY.md.

Fix

A fix for this was introduced in this commit: https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T17:34:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn `assert`-based security check in vLLM\u0027s activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (`python -O` or `PYTHONOPTIMIZE=1`).\n\n### Details\n\nvLLM uses an `assert` statement at [`vllm/model_executor/layers/pooler/activations.py:48`](https://github.com/vllm-project/vllm/blob/main/vllm/model_executor/layers/pooler/activations.py#L48) as its sole security control to restrict which activation functions can be loaded from a HuggingFace model\u0027s `config.json`:\n\n```python\n# vllm/model_executor/layers/pooler/activations.py:35-53\nfunction_name: str | None = None\nif (\n    hasattr(config, \"sentence_transformers\")\n    and \"activation_fn\" in config.sentence_transformers\n):\n    function_name = config.sentence_transformers[\"activation_fn\"]\nelif (\n    hasattr(config, \"sbert_ce_default_activation_function\")\n    and config.sbert_ce_default_activation_function is not None\n):\n    function_name = config.sbert_ce_default_activation_function\n\nif function_name is not None:\n    assert function_name.startswith(\"torch.nn.modules.\"), (\n        \"Loading of activation functions is restricted to \"\n        \"torch.nn.modules for security reasons\"\n    )\n    fn = resolve_obj_by_qualname(function_name)()\n```\n\nPython\u0027s `assert` statements are stripped at compile time when running in optimized mode (`python -O` or `PYTHONOPTIMIZE=1`). When the assert is absent, the attacker-controlled `function_name` from the model\u0027s `config.json` is passed directly to [`resolve_obj_by_qualname()`](https://github.com/vllm-project/vllm/blob/main/vllm/utils/import_utils.py#L106) \u2014 an unrestricted import gadget:\n\n```python\ndef resolve_obj_by_qualname(qualname: str) -\u003e Any:\n    module_name, obj_name = qualname.rsplit(\".\", 1)\n    module = importlib.import_module(module_name)\n    return getattr(module, obj_name)\n```\n\nThis is the same vulnerability class as **CVE-2017-1000433** (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).\n\n**Attacker-controlled input sources:**\n- `config.sentence_transformers[\"activation_fn\"]` (line 40)\n- `config.sbert_ce_default_activation_function` (line 45)\n\n**Affected call sites** \u2014 `get_act_fn()` is called via `resolve_classifier_act_fn()` from:\n- `vllm/model_executor/layers/pooler/seqwise/poolers.py:122` \u2014 SequencePooler\n- `vllm/model_executor/layers/pooler/tokwise/poolers.py:130` \u2014 TokenPooler\n\n**Broader systemic risk:** `resolve_obj_by_qualname` is called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.\n\n**Suggested fix:** Replace the `assert` with an explicit conditional raise:\n\n```python\nif not function_name.startswith(\"torch.nn.modules.\"):\n    raise ValueError(\n        \"Loading of activation functions is restricted to \"\n        \"torch.nn.modules for security reasons\"\n    )\n```\n\n### Impact\n\n**Arbitrary code execution.** A malicious model author publishes a HuggingFace model with a crafted `config.json`. When a victim loads this model with vLLM running under `python -O` or `PYTHONOPTIMIZE=1`, arbitrary code executes during model initialization with the privileges of the vLLM process.\n\nThe attack requires:\n1. Victim loads a malicious model from HuggingFace (user interaction)\n2. vLLM runs under `python -O` or `PYTHONOPTIMIZE=1` (documented in production use)\n3. Model uses a cross-encoder architecture (e.g. BERT or RoBERTa with sequence classification)\n\n**Coordinated disclosure note:** This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM\u0027s stated preferred disclosure channel per SECURITY.md.\n\n### Fix\n\nA fix for this was introduced in this commit: https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3",
  "id": "GHSA-q8gq-377p-jq3r",
  "modified": "2026-06-16T17:34:49Z",
  "published": "2026-06-16T17:34:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-q8gq-377p-jq3r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution"
}

GHSA-Q8HX-MM92-4WVG

Vulnerability from github – Published: 2024-10-09 19:14 – Updated: 2026-06-08 20:00

Summary

wasmtime has a runtime crash when combining tail calls with trapping imports

Details

Impact

Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later.

WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations.

The specific crash happens when an exported function in a WebAssembly module (or component) performs a return_call (or return_call_indirect or return_call_ref) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it's possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust panic!().

When Wasmtime is compiled with Rust versions 1.80 and prior this means that an extern "C" function in Rust is raising a panic!(). This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort.

Overall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more.

This issue was discovered by routine fuzzing performed by the Wasmtime project via Google's OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild.

Patches

All versions of Wasmtime which have tail calls enabled by default have been patched:

21.0.x - patched in 21.0.2
22.0.x - patched in 22.0.1
23.0.x - patched in 23.0.3
24.0.x - patched in 24.0.1
25.0.x - patched in 25.0.2

Wasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime.

Workarounds

The main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with Config::wasm_tail_call(false). Users are otherwise encouraged to upgrade to patched versions.

References

Severity

5.5 (Medium)


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

6.8 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "21.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.0.0"
            },
            {
              "fixed": "24.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-09T19:14:03Z",
    "nvd_published_at": "2024-10-09T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWasmtime\u0027s implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later.\n\n[WebAssembly tail calls](https://github.com/webassembly/tail-call) are a proposal which relatively recently reached stage 4 in the [standardization process](https://github.com/WebAssembly/proposals/). Wasmtime first enabled support for tail calls by default [in Wasmtime 21.0.0](https://github.com/bytecodealliance/wasmtime/pull/8540), although that release contained a bug where it was only on-by-default for some configurations. In [Wasmtime 22.0.0](https://github.com/bytecodealliance/wasmtime/pull/8682) tail calls were enabled by default for all configurations.\n\nThe specific crash happens when an exported function in a WebAssembly module (or component) performs a `return_call` (or `return_call_indirect` or `return_call_ref`) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it\u0027s possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust `panic!()`.\n\nWhen Wasmtime is compiled with Rust versions 1.80 and prior this means that an `extern \"C\"` function in Rust is raising a `panic!()`. This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort.\n\nOverall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more.\n\nThis issue was discovered by routine fuzzing performed by the Wasmtime project via Google\u0027s OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild.\n\n### Patches\n\nAll versions of Wasmtime which have tail calls enabled by default have been patched:\n\n* 21.0.x - patched in 21.0.2\n* 22.0.x - patched in 22.0.1\n* 23.0.x - patched in 23.0.3 \n* 24.0.x - patched in 24.0.1\n* 25.0.x - patched in 25.0.2\n\nWasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime.\n\n### Workarounds\n\nThe main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with [`Config::wasm_tail_call(false)`](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call). Users are otherwise encouraged to upgrade to patched versions.\n\n### References\n\n* [Wasmtime\u0027s initial implementation of tail calls](https://github.com/bytecodealliance/wasmtime/pull/6774)\n* [Enabling of tail calls in 21.0.0](https://github.com/bytecodealliance/wasmtime/pull/8540)\n* [Fully enabling tail calls in 22.0.0](https://github.com/bytecodealliance/wasmtime/pull/8682)\n* [The WebAssembly\u0027s `tail-call` proposal](https://github.com/webassembly/tail-call)",
  "id": "GHSA-q8hx-mm92-4wvg",
  "modified": "2026-06-08T20:00:05Z",
  "published": "2024-10-09T19:14:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47763"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/6774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/8540"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/8682"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/0ebe54d05f0e1f6c64b7c8bb48c9e9f6c95cacba"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WebAssembly/proposals"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime-bin/PYSEC-2024-312.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webassembly/tail-call"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0440.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "wasmtime has a runtime crash when combining tail calls with trapping imports"
}

GHSA-Q8JQ-R84F-F54X

Vulnerability from github – Published: 2022-01-21 00:00 – Updated: 2022-01-27 00:02

Details

There is an Assertion 'opts & PARSER_CLASS_LITERAL_CTOR_PRESENT' failed at /parser/js/js-parser-expr.c(parser_parse_class_body) in JerryScript 3.0.0.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-46336"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-20T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is an Assertion \u0027opts \u0026 PARSER_CLASS_LITERAL_CTOR_PRESENT\u0027 failed at /parser/js/js-parser-expr.c(parser_parse_class_body) in JerryScript 3.0.0.",
  "id": "GHSA-q8jq-r84f-f54x",
  "modified": "2022-01-27T00:02:36Z",
  "published": "2022-01-21T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46336"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/issues/4927"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q97V-2CP6-JV6P

Vulnerability from github – Published: 2024-11-04 12:32 – Updated: 2024-11-04 12:32

Details

Transient DOS as modem reset occurs when an unexpected MAC RAR (with invalid PDU length) is seen at UE.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-23385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T10:15:04Z",
    "severity": "HIGH"
  },
  "details": "Transient DOS as modem reset occurs when an unexpected MAC RAR (with invalid PDU length) is seen at UE.",
  "id": "GHSA-q97v-2cp6-jv6p",
  "modified": "2024-11-04T12:32:56Z",
  "published": "2024-11-04T12:32:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23385"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/november-2024-bulletin.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC53-44CJ-VFVX

Vulnerability from github – Published: 2020-09-25 18:28 – Updated: 2024-10-28 20:24

Summary

Denial of Service in Tensorflow

Details

Impact

The SparseCountSparseOutput implementation does not validate that the input arguments form a valid sparse tensor. In particular, there is no validation that the indices tensor has rank 2. This tensor must be a matrix because code assumes its elements are accessed as elements of a matrix: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L185

However, malicious users can pass in tensors of different rank, resulting in a CHECK assertion failure and a crash. This can be used to cause denial of service in serving installations, if users are allowed to control the components of the input sparse tensor.

Patches

We have patched the issue in 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and will release a patch release.

We recommend users to upgrade to TensorFlow 2.3.1.

For more information

Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution

This vulnerability is a variant of GHSA-p5f8-gfw5-33w4

Severity

6.3 (Medium)


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

4.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-617"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-09-25T17:18:05Z",
    "nvd_published_at": "2020-09-25T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe `SparseCountSparseOutput` implementation does not validate that the input arguments form a valid sparse tensor. In particular, there is no validation that the `indices` tensor has rank 2. This tensor must be a matrix because code assumes its elements are accessed as elements of a matrix:\nhttps://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L185\n\nHowever, malicious users can pass in tensors of different rank, resulting in a `CHECK` assertion failure and a crash. This can be used to cause denial of service in serving installations, if users are allowed to control the components of the input sparse tensor.\n\n### Patches\nWe have patched the issue in 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and will release a patch release.\n\nWe recommend users to upgrade to TensorFlow 2.3.1.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability is a variant of [GHSA-p5f8-gfw5-33w4](https://github.com/tensorflow/tensorflow/security/advisories/GHSA-p5f8-gfw5-33w4)",
  "id": "GHSA-qc53-44cj-vfvx",
  "modified": "2024-10-28T20:24:30Z",
  "published": "2020-09-25T18:28:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-qc53-44cj-vfvx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2020-277.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2020-312.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2020-120.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Denial of Service in Tensorflow"
}

GHSA-QCJC-QMXQ-WF6X

Vulnerability from github – Published: 2025-01-22 15:32 – Updated: 2025-02-07 03:32

Details

Open5GS MME versions <= 2.6.4 contain an assertion that can be remotely triggered via a malformed ASN.1 packet over the S1AP interface. An attacker may send an S1Setup Request message missing a required Global eNB ID field to repeatedly crash the MME, resulting in denial of service.

Severity

8.6 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-37017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-22T15:15:11Z",
    "severity": "HIGH"
  },
  "details": "Open5GS MME versions \u003c= 2.6.4 contain an assertion that can be remotely triggered via a malformed ASN.1 packet over the S1AP interface. An attacker may send an `S1Setup Request` message missing a required `Global eNB ID` field to repeatedly crash the MME, resulting in denial of service.",
  "id": "GHSA-qcjc-qmxq-wf6x",
  "modified": "2025-02-07T03:32:00Z",
  "published": "2025-01-22T15:32:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37017"
    },
    {
      "type": "WEB",
      "url": "https://cellularsecurity.org/ransacked"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QF95-V28G-MJGX

Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30

Details

In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01270690; Issue ID: MSV-4301.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-20752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T03:16:16Z",
    "severity": "MODERATE"
  },
  "details": "In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01270690; Issue ID: MSV-4301.",
  "id": "GHSA-qf95-v28g-mjgx",
  "modified": "2025-12-02T15:30:30Z",
  "published": "2025-12-02T03:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20752"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-617

Reachable Assertion

GHSA-Q6XR-Q445-2XXH

GHSA-Q778-7MC2-5QMC

GHSA-Q858-Q2J2-9JG4

GHSA-Q8GQ-377P-JQ3R

Summary

Details

Impact

Fix

GHSA-Q8HX-MM92-4WVG

Impact

Patches

Workarounds

References

GHSA-Q8JQ-R84F-F54X

GHSA-Q97V-2CP6-JV6P

GHSA-QC53-44CJ-VFVX

Impact

Patches

For more information

Attribution

GHSA-QCJC-QMXQ-WF6X

GHSA-QF95-V28G-MJGX

Mitigation

Mitigation