Common Weakness Enumeration

CWE-681

Allowed

Incorrect Conversion between Numeric Types

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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.

163 vulnerabilities reference this CWE, most recent first.

GHSA-4V58-74MF-RJX3

Vulnerability from github – Published: 2026-09-17 17:04 – Updated: 2026-09-17 17:04
VLAI
Summary
RabbitMQ amqp091-go: Denial of Service via Malicious Field Length in AMQP Client
Details

Summary A vulnerability in the readField function allows a malicious or compromised AMQP server to trigger an unhandled runtime panic in the client application, leading to an immediate crash of the entire process.

Details When parsing incoming AMQP frames, the readField function processes byte-array fields (type tag 'x') by reading a 32-bit big-endian integer to determine the length of the data payload.

// read.go:253-263
case 'x':
    var len int32
    if err = binary.Read(r, binary.BigEndian, &len); err != nil {
        return nil, err
    }
    value := make([]byte, len)  // PANICS if len < 0

If a server transmits a length value of 0xFFFFFFFF, it is interpreted by the client as a signed 32-bit integer with a value of -1. Passing a negative integer to Go's built-in make() function for slice allocation triggers an unrecoverable runtime panic (panic: len out of range).

Because the reader goroutine handles network I/O without an explicit recover() wrapper, this panic propagates up to the runtime root, abruptly terminating the host application.

Attack Vector / Exploitation Scenario An attacker capable of spoofing, compromising, or controlling an AMQP broker can exploit this flaw during two primary phases:

  1. Connection Establishment: Sending a malicious connection.start handshake frame containing server-properties with an 'x' type field assigned a negative length.
  2. Message Delivery: Delivering a message payload where the header table contains a malformed field matching the criteria above.

Impact Availability: High. A single malformed frame can reliably crash the client process, resulting in a persistent Denial of Service (DoS) if the client automatically reconnects and receives the same payload.

Severity
8.9 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rabbitmq/amqp091-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:04:29Z",
    "nvd_published_at": "2026-09-16T15:17:50Z",
    "severity": "HIGH"
  },
  "details": "**Summary**\nA vulnerability in the readField function allows a malicious or compromised AMQP server to trigger an unhandled runtime panic in the client application, leading to an immediate crash of the entire process.\n\n**Details**\nWhen parsing incoming AMQP frames, the `readField` function processes byte-array fields (type tag `\u0027x\u0027`) by reading a 32-bit big-endian integer to determine the length of the data payload.\n\n```go\n// read.go:253-263\ncase \u0027x\u0027:\n    var len int32\n    if err = binary.Read(r, binary.BigEndian, \u0026len); err != nil {\n        return nil, err\n    }\n    value := make([]byte, len)  // PANICS if len \u003c 0\n```\n\nIf a server transmits a length value of `0xFFFFFFFF`, it is interpreted by the client as a signed 32-bit integer with a value of `-1`. Passing a negative integer to Go\u0027s built-in make() function for slice allocation triggers an unrecoverable runtime panic (panic: len out of range).\n\nBecause the reader goroutine handles network I/O without an explicit recover() wrapper, this panic propagates up to the runtime root, abruptly terminating the host application.\n\n**Attack Vector / Exploitation Scenario**\nAn attacker capable of spoofing, compromising, or controlling an AMQP broker can exploit this flaw during two primary phases:\n\n1. Connection Establishment: Sending a malicious connection.start handshake frame containing server-properties with an \u0027x\u0027 type field assigned a negative length.\n2. Message Delivery: Delivering a message payload where the header table contains a malformed field matching the criteria above.\n\n**Impact**\nAvailability: High. A single malformed frame can reliably crash the client process, resulting in a persistent Denial of Service (DoS) if the client automatically reconnects and receives the same payload.",
  "id": "GHSA-4v58-74mf-rjx3",
  "modified": "2026-09-17T17:04:29Z",
  "published": "2026-09-17T17:04:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-4v58-74mf-rjx3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77412"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/pull/344"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/commit/669b42bf7b1db76bc6d4973e3634247f680accbf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/amqp091-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RabbitMQ amqp091-go: Denial of Service via Malicious Field Length in AMQP Client"
}

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."

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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-5G8V-HHJF-5G8C

Vulnerability from github – Published: 2026-08-10 09:31 – Updated: 2026-08-19 18:32
VLAI
Details

Incorrect conversion between numeric types in VC1 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
5.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-21069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T09:17:20Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect conversion between numeric types in VC1 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory.",
  "id": "GHSA-5g8v-hhjf-5g8c",
  "modified": "2026-08-19T18:32:04Z",
  "published": "2026-08-10T09:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21069"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2026\u0026month=08"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5JV2-G5WQ-CMR4

Vulnerability from github – Published: 2026-06-17 14:03 – Updated: 2026-07-17 16:20
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

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.5"
            },
            {
              "fixed": "0.24.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": "2026-06-22T23:16:30Z",
    "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-07-17T16:20:57Z",
  "published": "2026-06-17T14:03:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-5jv2-g5wq-cmr4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53923"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/44971"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/f219788f91952827132fa4fdf916427cd20d225e"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-5jv2-g5wq-cmr4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3403.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "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.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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.

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
To clipboard 

{
  "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: 2026-10-14 09:31
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.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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": "2026-10-14T09:31:24Z",
  "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/html/ssa-389290.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "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
To clipboard 

{
  "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-6CG8-27Q5-77WX

Vulnerability from github – Published: 2026-09-24 21:32 – Updated: 2026-09-29 03:30
VLAI
Details

LibRaw 0.22.0 contains an incorrect numeric conversion vulnerability in LibRaw::parse_tiff_ifd() when processing TIFF tag 0x00fe (NewSubfileType). A specially crafted RAW, TIFF, or DNG file can supply an attacker-controlled NewSubfileType value outside the range of a signed int. The parser converts this value and narrows it to int without performing range validation. This out-of-range conversion triggers undefined behavior, resulting in process termination and denial of service.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-88387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T21:18:57Z",
    "severity": "MODERATE"
  },
  "details": "LibRaw 0.22.0 contains an incorrect numeric conversion vulnerability in LibRaw::parse_tiff_ifd() when processing TIFF tag 0x00fe (NewSubfileType). A specially crafted RAW, TIFF, or DNG file can supply an attacker-controlled NewSubfileType value outside the range of a signed int. The parser converts this value and narrows it to int without performing range validation. This out-of-range conversion triggers undefined behavior, resulting in process termination and denial of service.",
  "id": "GHSA-6cg8-27q5-77wx",
  "modified": "2026-09-29T03:30:40Z",
  "published": "2026-09-24T21:32:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88387"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LibRaw/LibRaw/issues/844"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LibRaw/LibRaw/pull/853"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LibRaw/LibRaw/commit/b41cbbd61951783e0440590dae55411a16185bdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FH5-PXVV-CCVW

Vulnerability from github – Published: 2026-08-19 18:32 – Updated: 2026-08-19 18:32
VLAI
Details

FFmpeg before commit b4c199c contains an incorrect integer narrowing conversion in the AV1 RTP packetizer (libavformat/rtpenc_av1.c). The OBU size is cast to long before comparison against the remaining frame size. On targets where long is 32 bits, including 64-bit Windows, sufficiently large OBU size values are sign-flipped by the narrowing cast, producing a negative value that passes the payload size check. This allows an oversized OBU to bypass the safety bound on affected platforms, leading to out-of-bounds memory access when the oversized value is subsequently used as a copy length.

Severity
5.8 (Medium)
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:H
5.8 (Medium)
CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-75145"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-19T17:21:12Z",
    "severity": "MODERATE"
  },
  "details": "FFmpeg before commit b4c199c contains an incorrect integer narrowing conversion in the AV1 RTP packetizer (libavformat/rtpenc_av1.c). The OBU size is cast to long before comparison against the remaining frame size. On targets where long is 32 bits, including 64-bit Windows, sufficiently large OBU size values are sign-flipped by the narrowing cast, producing a negative value that passes the payload size check. This allows an oversized OBU to bypass the safety bound on affected platforms, leading to out-of-bounds memory access when the oversized value is subsequently used as a copy length.",
  "id": "GHSA-6fh5-pxvv-ccvw",
  "modified": "2026-08-19T18:32:51Z",
  "published": "2026-08-19T18:32:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75145"
    },
    {
      "type": "WEB",
      "url": "https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/b4c199c5906ff53368926c2a5839881f41957e7f"
    },
    {
      "type": "WEB",
      "url": "https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24090"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ffmpeg-integer-narrowing-conversion-oob-memory-access-in-av1-rtp-packetizer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Implementation

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

No CAPEC attack patterns related to this CWE.

← Back to the CWE list