Common Weakness Enumeration

CWE-681

Allowed

Incorrect Conversion between Numeric Types

Abstraction: Base · Status: Draft

When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.

126 vulnerabilities reference this CWE, most recent first.

GHSA-4456-W38R-M53X

Vulnerability from github – Published: 2022-09-23 20:24 – Updated: 2022-09-23 20:24
VLAI
Summary
Besu VM vulnerable to gas allocation error in CALL operations
Details

Impact

An error in 32 bit signed and unsigned types in the calculation of available gas in the CALL operations (including DELEGATECALL) results in incorrect gas being passed into called contracts and incorrect gas being returned after call execution. Where the amount of gas makes a difference in the success or failure, or if the gas is a negative 64 bit value, the execution will result in a different state root than expected, resulting in a consensus failure in networks with multiple EVM implementations.

In networks with a single EVM implementation this can be used to execute with significantly more gas than then transaction requested, possibly exceeding gas limitations.

Patches

Version 22.7.1 contains a fix, ensuring that excess gas will not be allocated to inner transaction calls and correcting the excess gas errors.

Workarounds

Reverting to version 22.1.3 or earlier will prevent incorrect execution. However many ethereum mainnet networks require changes in more recent versions of Besu and should not use older versions of besu and should instead use the patched version.

Ethereum Classic and other networks not depending on a Proof of Stake transition should function fine with version 22.1.3 or earlier.

For more information

Issue was found by Martin Holst Swende using goevmlab, it is believed that no production networks have transactions that would trigger this failure.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.hyperledger.besu:evm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.4.0-RC1"
            },
            {
              "fixed": "22.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36025"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-196",
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-23T20:24:21Z",
    "nvd_published_at": "2022-09-24T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nAn error in 32 bit signed and unsigned types in the calculation of available gas in the CALL operations (including DELEGATECALL) results in incorrect gas being passed into called contracts and incorrect gas being returned after call execution.  Where the amount of gas makes a difference in the success or failure, or if the gas is a negative 64 bit value, the execution will result in a different state root than expected, resulting in a consensus failure in networks with multiple EVM implementations. \n\nIn networks with a single EVM implementation this can be used to execute with significantly more gas than then transaction requested, possibly exceeding gas limitations. \n\n### Patches\nVersion 22.7.1 contains a fix, ensuring that excess gas will not be allocated to inner transaction calls and correcting the excess gas errors.\n\n### Workarounds\nReverting to version 22.1.3 or earlier will prevent incorrect execution. However many ethereum mainnet networks require changes in more recent versions of Besu and should not use older versions of besu and should instead use the patched version.  \n\nEthereum Classic and other networks not depending on a Proof of Stake transition should function fine with version 22.1.3 or earlier.\n\n### For more information\nIssue was found by [Martin Holst Swende](https://github.com/holiman) using [goevmlab](https://github.com/holiman/goevmlab), it is believed that no production networks have transactions that would trigger this failure.\n\n",
  "id": "GHSA-4456-w38r-m53x",
  "modified": "2022-09-23T20:24:21Z",
  "published": "2022-09-23T20:24:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/besu/security/advisories/GHSA-4456-w38r-m53x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36025"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hyperledger/besu"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Besu VM vulnerable to gas allocation error in CALL operations"
}

GHSA-488P-W8X3-XH6M

Vulnerability from github – Published: 2023-03-20 21:30 – Updated: 2023-03-23 21:30
VLAI
Details

An integer conversion vulnerability exists in the SORBAx64.dll RecvPacket functionality of WellinTech KingHistorian 35.01.00.05. A specially crafted network packet can lead to a buffer overflow. An attacker can send a malicious packet to trigger this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-43663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-195",
      "CWE-681",
      "CWE-704"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-20T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An integer conversion vulnerability exists in the SORBAx64.dll RecvPacket functionality of WellinTech KingHistorian 35.01.00.05. A specially crafted network packet can lead to a buffer overflow. An attacker can send a malicious packet to trigger this vulnerability.",
  "id": "GHSA-488p-w8x3-xh6m",
  "modified": "2023-03-23T21:30:20Z",
  "published": "2023-03-20T21:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43663"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1674"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4Q7H-5C9F-8XQG

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

An exploitable integer truncation vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an improper memory allocation resulting in a heap-based buffer overflow that causes memory corruption. The FOURCC code, 'trik', is parsed by the function within the library. An attacker can convince a user to open a video to trigger this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-21860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable integer truncation vulnerability exists within the MPEG-4 decoding functionality of the GPAC Project on Advanced Content library v1.0.1. A specially crafted MPEG-4 input can cause an improper memory allocation resulting in a heap-based buffer overflow that causes memory corruption. The FOURCC code, \u0027trik\u0027, is parsed by the function within the library. An attacker can convince a user to open a video to trigger this vulnerability.",
  "id": "GHSA-4q7h-5c9f-8xqg",
  "modified": "2022-05-24T19:11:11Z",
  "published": "2022-05-24T19:11:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21860"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1298"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4966"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-56XW-8WF9-J3X9

Vulnerability from github – Published: 2022-05-02 03:13 – Updated: 2024-02-08 03:32
VLAI
Details

The Embedded OpenType (EOT) Font Engine (T2EMBED.DLL) in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP2, Vista Gold, SP1, and SP2, and Server 2008 Gold and SP2 allows remote attackers to execute arbitrary code via a crafted name table in a data record that triggers an integer truncation and a heap-based buffer overflow, aka "Embedded OpenType Font Heap Overflow Vulnerability."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-0231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-07-15T15:30:00Z",
    "severity": "HIGH"
  },
  "details": "The Embedded OpenType (EOT) Font Engine (T2EMBED.DLL) in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP2, Vista Gold, SP1, and SP2, and Server 2008 Gold and SP2 allows remote attackers to execute arbitrary code via a crafted name table in a data record that triggers an integer truncation and a heap-based buffer overflow, aka \"Embedded OpenType Font Heap Overflow Vulnerability.\"",
  "id": "GHSA-56xw-8wf9-j3x9",
  "modified": "2024-02-08T03:32:44Z",
  "published": "2022-05-02T03:13:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0231"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-029"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5457"
    },
    {
      "type": "WEB",
      "url": "http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=811"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/55842"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1022543"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA09-195A.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/1887"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5JV2-G5WQ-CMR4

Vulnerability from github – Published: 2026-06-17 14:03 – Updated: 2026-06-17 14:03
VLAI
Summary
vLLM: GGUF dequantize kernel int truncation exposes uninitialized GPU memory in multi-tenant serving
Details

Summary

Integer truncation of tensor dimensions in vLLM's GGUF dequantize kernels (csrc/quantization/gguf/gguf_kernel.cu) causes partial tensor processing. The output tensor is allocated at full size via torch::empty (uninitialized memory), but the dequantize CUDA kernel processes only a truncated number of elements. The unfilled portion of the output tensor retains whatever was previously in GPU memory. In multi-tenant inference deployments, this residual GPU memory may contain tensor data from other users' inference requests, constituting information disclosure.

Root Cause

The to_cuda_ggml_t function pointer type at ggml-common.h:1067 declares its element count parameter as int (32-bit):

using to_cuda_ggml_t = void (*)(const void * __restrict__ x,
                                dst_t * __restrict__ y,
                                int k,              // 32-bit
                                cudaStream_t stream);

All dequantize kernel functions (dequantize_block_cuda, dequantize_row_q2_K_cuda, etc. in dequantize.cuh) inherit this int k parameter and use it as the kernel launch grid size:

static void dequantize_block_cuda(..., const int k, cudaStream_t stream) {
    const int num_blocks = (k + 2*CUDA_DEQUANTIZE_BLOCK_SIZE - 1) / (2*CUDA_DEQUANTIZE_BLOCK_SIZE);
    dequantize_block<<<num_blocks, CUDA_DEQUANTIZE_BLOCK_SIZE, 0, stream>>>(vx, y, k);
}

In ggml_dequantize() at gguf_kernel.cu:85, the caller passes m * n (an int64_t product) to this int k parameter:

at::Tensor DW = torch::empty({m, n}, options);    // line 80: full-size, UNINITIALIZED
// ...
to_cuda((void*)W.data_ptr(), (scalar_t*)DW.data_ptr(), m * n, stream);  // line 85: m*n truncated to int

When m * n > INT_MAX, the truncated k is smaller than the actual tensor size. The kernel processes k elements. The remaining (m * n) - k elements in DW are never written and contain stale GPU memory.

This is a single root cause -- the int type on the k parameter in to_cuda_ggml_t -- with a single fix: change int k to int64_t k. All dequantize functions inherit this type through the same typedef.

Affected Functions

All in csrc/quantization/gguf/gguf_kernel.cu:

Function Line Allocation Info Disclosure?
ggml_dequantize 74 torch::empty({m, n}) at line 80 Yes -- m*n truncated to int k at line 85
ggml_mul_mat_vec_a8 91 torch::empty({vecs, row}) at line 99 Yes -- int col = X.sizes()[1] at line 94
ggml_mul_mat_a8 207 torch::empty({batch, row}) at line 215 Yes -- int col = X.sizes()[1] at line 210
ggml_moe_a8 279 torch::empty({tokens*top_k, row}) at line 289 Yes -- int col = X.sizes()[1] at line 285

All four functions allocate output tensors with torch::empty (uninitialized) and then run CUDA kernels that use truncated dimension values as loop bounds. The unfilled portion of each output tensor retains stale GPU memory.

ggml_moe_a8_vec (line 382) uses torch::zeros instead of torch::empty, so it is not affected by the info disclosure variant.

Impact: Information Disclosure in Multi-Tenant Serving

vLLM is designed for multi-tenant inference serving. GPU memory is reused across requests from different users. When the dequantize kernel partially fills an output tensor:

  1. The output tensor DW is allocated with torch::empty -- the buffer contains whatever was previously in that GPU memory region
  2. The dequantize kernel fills only a truncated portion of the buffer
  3. The unfilled portion retains residual data from prior GPU operations, which may include tensor data from other users' inference requests
  4. The contaminated tensor proceeds through the model computation
  5. No error or warning is generated -- the partial fill is silent

This is a confidentiality violation. In shared inference deployments (the primary vLLM use case), one user's inference data can leak into another user's model computation through residual GPU memory.

Attacker Control

The attacker crafts a GGUF model file with weight tensor dimensions whose product exceeds INT_MAX (e.g., a matrix with shape [65536, 65536] gives m * n = 4,294,967,296). The model is hosted on HuggingFace or any model hub. The victim loads the model with vLLM for inference serving. The truncation happens automatically during model weight dequantization.

Fix

A fix for this vulnerability was added here: https://github.com/vllm-project/vllm/pull/44971

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.5"
            },
            {
              "last_affected": "0.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:03:11Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nInteger truncation of tensor dimensions in vLLM\u0027s GGUF dequantize kernels (`csrc/quantization/gguf/gguf_kernel.cu`) causes partial tensor processing. The output tensor is allocated at full size via `torch::empty` (uninitialized memory), but the dequantize CUDA kernel processes only a truncated number of elements. The unfilled portion of the output tensor retains whatever was previously in GPU memory. In multi-tenant inference deployments, this residual GPU memory may contain tensor data from other users\u0027 inference requests, constituting information disclosure.\n\n## Root Cause\n\nThe `to_cuda_ggml_t` function pointer type at `ggml-common.h:1067` declares its element count parameter as `int` (32-bit):\n\n```cpp\nusing to_cuda_ggml_t = void (*)(const void * __restrict__ x,\n                                dst_t * __restrict__ y,\n                                int k,              // 32-bit\n                                cudaStream_t stream);\n```\n\nAll dequantize kernel functions (`dequantize_block_cuda`, `dequantize_row_q2_K_cuda`, etc. in `dequantize.cuh`) inherit this `int k` parameter and use it as the kernel launch grid size:\n\n```cpp\nstatic void dequantize_block_cuda(..., const int k, cudaStream_t stream) {\n    const int num_blocks = (k + 2*CUDA_DEQUANTIZE_BLOCK_SIZE - 1) / (2*CUDA_DEQUANTIZE_BLOCK_SIZE);\n    dequantize_block\u003c\u003c\u003cnum_blocks, CUDA_DEQUANTIZE_BLOCK_SIZE, 0, stream\u003e\u003e\u003e(vx, y, k);\n}\n```\n\nIn `ggml_dequantize()` at `gguf_kernel.cu:85`, the caller passes `m * n` (an `int64_t` product) to this `int k` parameter:\n\n```cpp\nat::Tensor DW = torch::empty({m, n}, options);    // line 80: full-size, UNINITIALIZED\n// ...\nto_cuda((void*)W.data_ptr(), (scalar_t*)DW.data_ptr(), m * n, stream);  // line 85: m*n truncated to int\n```\n\nWhen `m * n \u003e INT_MAX`, the truncated `k` is smaller than the actual tensor size. The kernel processes `k` elements. The remaining `(m * n) - k` elements in `DW` are never written and contain stale GPU memory.\n\nThis is a single root cause -- the `int` type on the `k` parameter in `to_cuda_ggml_t` -- with a single fix: change `int k` to `int64_t k`. All dequantize functions inherit this type through the same typedef.\n\n## Affected Functions\n\nAll in `csrc/quantization/gguf/gguf_kernel.cu`:\n\n| Function | Line | Allocation | Info Disclosure? |\n|----------|------|-----------|-----------------|\n| `ggml_dequantize` | 74 | `torch::empty({m, n})` at line 80 | Yes -- `m*n` truncated to `int k` at line 85 |\n| `ggml_mul_mat_vec_a8` | 91 | `torch::empty({vecs, row})` at line 99 | Yes -- `int col = X.sizes()[1]` at line 94 |\n| `ggml_mul_mat_a8` | 207 | `torch::empty({batch, row})` at line 215 | Yes -- `int col = X.sizes()[1]` at line 210 |\n| `ggml_moe_a8` | 279 | `torch::empty({tokens*top_k, row})` at line 289 | Yes -- `int col = X.sizes()[1]` at line 285 |\n\nAll four functions allocate output tensors with `torch::empty` (uninitialized) and then run CUDA kernels that use truncated dimension values as loop bounds. The unfilled portion of each output tensor retains stale GPU memory.\n\n`ggml_moe_a8_vec` (line 382) uses `torch::zeros` instead of `torch::empty`, so it is not affected by the info disclosure variant.\n\n## Impact: Information Disclosure in Multi-Tenant Serving\n\nvLLM is designed for multi-tenant inference serving. GPU memory is reused across requests from different users. When the dequantize kernel partially fills an output tensor:\n\n1. The output tensor `DW` is allocated with `torch::empty` -- the buffer contains whatever was previously in that GPU memory region\n2. The dequantize kernel fills only a truncated portion of the buffer\n3. The unfilled portion retains residual data from prior GPU operations, which may include tensor data from other users\u0027 inference requests\n4. The contaminated tensor proceeds through the model computation\n5. No error or warning is generated -- the partial fill is silent\n\nThis is a confidentiality violation. In shared inference deployments (the primary vLLM use case), one user\u0027s inference data can leak into another user\u0027s model computation through residual GPU memory.\n\n## Attacker Control\n\nThe attacker crafts a GGUF model file with weight tensor dimensions whose product exceeds `INT_MAX` (e.g., a matrix with shape `[65536, 65536]` gives `m * n = 4,294,967,296`). The model is hosted on HuggingFace or any model hub. The victim loads the model with vLLM for inference serving. The truncation happens automatically during model weight dequantization.\n\n## Fix\n\nA fix for this vulnerability was added here: https://github.com/vllm-project/vllm/pull/44971",
  "id": "GHSA-5jv2-g5wq-cmr4",
  "modified": "2026-06-17T14:03:11Z",
  "published": "2026-06-17T14:03:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-5jv2-g5wq-cmr4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/44971"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/f219788f91952827132fa4fdf916427cd20d225e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vLLM: GGUF dequantize kernel int truncation exposes uninitialized GPU memory in multi-tenant serving"
}

GHSA-5RWX-CQG3-893X

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-28 09:31
VLAI
Details

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

RDMA/umem: Fix truncation for block sizes >= 4G

When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries.

When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation.

Use the right types to hold DMA addresses.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:30Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umem: Fix truncation for block sizes \u003e= 4G\n\nWhen the iommu is used the linearization of the mapping can give a single\nblock that is very large split across multiple SG entries.\n\nWhen __rdma_block_iter_next() reassembles the split SG entries it is\noverflowing the 32 bit stack values and computed the wrong DMA addresses\nfor blocks after the truncation.\n\nUse the right types to hold DMA addresses.",
  "id": "GHSA-5rwx-cqg3-893x",
  "modified": "2026-06-28T09:31:42Z",
  "published": "2026-06-25T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53133"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15fe76e23615f502d051ef0768f86babaf08746c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2ff4b7817e5b78070c30f5fb5e678e452a2628b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8fe0231adebe086c8a459c790944ac026cd99c6e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ac1aad8e1281534ce936c250f68084fc79c5469e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/afd35fec9297195b759078745549c2671223f24f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/baf8685bcf56dc1efb44b8f6a57c42516e549068"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc644d5608e3b0dadc970bd6e6aa26b91ea07d0f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dee2a49adeeb2a5e16a3fc858fa21b841c519802"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VP6-8MMJ-74FG

Vulnerability from github – Published: 2026-04-07 18:31 – Updated: 2026-04-07 18:31
VLAI
Details

NVIDIA Triton Inference Server contains a vulnerability where an attacker could cause a server crash by sending a malformed request to the server. A successful exploit of this vulnerability might lead to denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T18:16:39Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Triton Inference Server contains a vulnerability where an attacker could cause a server crash by sending a malformed request to the server. A successful exploit of this vulnerability might lead to denial of service.",
  "id": "GHSA-5vp6-8mmj-74fg",
  "modified": "2026-04-07T18:31:38Z",
  "published": "2026-04-07T18:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24174"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5816"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24174"
    }
  ],
  "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-6283-Q875-5QPP

Vulnerability from github – Published: 2022-05-24 17:02 – Updated: 2022-05-24 17:02
VLAI
Details

lookupName in resolve.c in SQLite 3.30.1 omits bits from the colUsed bitmask in the case of a generated column, which allows attackers to cause a denial of service or possibly have unspecified other impact.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-19317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-05T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "lookupName in resolve.c in SQLite 3.30.1 omits bits from the colUsed bitmask in the case of a generated column, which allows attackers to cause a denial of service or possibly have unspecified other impact.",
  "id": "GHSA-6283-q875-5qpp",
  "modified": "2022-05-24T17:02:43Z",
  "published": "2022-05-24T17:02:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19317"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sqlite/sqlite/commit/522ebfa7cee96fb325a22ea3a2464a63485886a8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sqlite/sqlite/commit/73bacb7f93eab9f4bd5a65cbc4ae242acf63c9e3"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20191223-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6552-8JMJ-F95C

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18
VLAI
Details

An issue was discovered in OpenPOWER 2.6 firmware. unpack_timestamp() calls le32_to_cpu() for endian conversion of a uint16_t "year" value, resulting in a type mismatch that can truncate a higher integer value to a smaller one, and bypass a timestamp check. The fix is to use the right endian conversion function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-36357"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-22T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in OpenPOWER 2.6 firmware. unpack_timestamp() calls le32_to_cpu() for endian conversion of a uint16_t \"year\" value, resulting in a type mismatch that can truncate a higher integer value to a smaller one, and bypass a timestamp check. The fix is to use the right endian conversion function.",
  "id": "GHSA-6552-8jmj-f95c",
  "modified": "2022-05-24T19:18:40Z",
  "published": "2022-05-24T19:18:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36357"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-power/skiboot/commit/5be38b672c1410e2f10acd3ad2eecfdc81d5daf7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6HF5-GQPW-H5WW

Vulnerability from github – Published: 2022-01-11 00:01 – Updated: 2025-04-17 21:30
VLAI
Details

The FANUC R-30iA and R-30iB series controllers are vulnerable to integer coercion errors, which cause the device to crash. A restart is required.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-32996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-192",
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T14:10:00Z",
    "severity": "HIGH"
  },
  "details": "The FANUC R-30iA and R-30iB series controllers are vulnerable to integer coercion errors, which cause the device to crash. A restart is required.",
  "id": "GHSA-6hf5-gqpw-h5ww",
  "modified": "2025-04-17T21:30:37Z",
  "published": "2022-01-11T00:01:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32996"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-243-02"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Implementation

Avoid making conversion between numeric types. Always check for the allowed ranges.

No CAPEC attack patterns related to this CWE.