Common Weakness Enumeration

CWE-125

Allowed

Out-of-bounds Read

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product reads data past the end, or before the beginning, of the intended buffer.

11292 vulnerabilities reference this CWE, most recent first.

GHSA-X5MV-8WGW-29HG

Vulnerability from github – Published: 2026-06-18 15:05 – Updated: 2026-06-18 15:05
VLAI
Summary
tract-nnef: integer overflow in NNEF `.dat` tensor parser yields an out-of-bounds read on model load
Details
  • Component: tract-nnef (nnef/src/tensors.rs::read_tensor) + tract-data (data/src/tensor.rs)
  • Affected versions: < 0.21.16, 0.22.0–0.22.2, 0.23.0–0.23.1 — the dense DatLoader path was unguarded across all three release lines; patched in 0.21.16 / 0.22.2 / 0.23.1
  • Class: CWE-190 (integer overflow) → CWE-125 (out-of-bounds read)
  • Trigger: loading a crafted NNEF model archive (*.nnef.tgz / *.nnef.tar / dir) via the public tract_nnef::nnef().model_for_path / model_for_read
  • Impact: read_tensor returns a memory-unsafe tensor (reported len 2^61 over a 56-byte heap allocation). Always-on primitive: a bounded heap out-of-bounds read during model build (as_uniform), an adjacent-heap information-disclosure reachable via the public load API. The resulting slice is an unsound from_raw_parts(ptr, 2^61) that SIGSEGVs (DoS) on any access past the mapped region (demonstrated by direct access). No out-of-bounds write and no RCE were achieved — tract's const-folding/as_uniform fast-paths fold simple consuming graphs without the full read.
  • Severity: Medium

Summary

read_tensor builds a tensor shape from attacker-controlled 32-bit dimensions and computes the element count len = product(shape) and the byte allocation product(shape) * size_of(dt) with unchecked usize arithmetic. In --release (no overflow-checks), both products wrap modulo 2^64. An attacker chooses dimensions so that the wrapped products collapse to a small value that satisfies the header consistency check, while the true element count remains astronomically large. read_tensor returns Ok with a Tensor whose reported len (e.g. 2^61+7) is far larger than its backing heap allocation (e.g. 56 bytes). The unchecked slice accessor as_slice_unchecked (from_raw_parts(ptr, self.len)) then produces a slice spanning ~18 exabytes over a 56-byte buffer. The out-of-bounds read fires automatically during model build (no inference required), reachable through the default DatLoader resource loader.

Root cause

nnef/src/tensors.rs, read_tensor:

let shape: TVec<usize> = header.dims[0..header.rank as usize].iter().map(|d| *d as _).collect();
let len = shape.iter().product::<usize>();                       // (1) unchecked, wraps
...
} else if header.bits_per_item != u32::MAX
    && len * (header.bits_per_item as usize / 8) != header.data_size_bytes as usize  // (2) wrapped == u32
{
    bail!(...);
}
...
let mut tensor = unsafe { Tensor::uninitialized_dt(dt, &shape)? };   // (3) alloc off the same wrapped product
...
reader.read_exact(plain.as_bytes_mut())?;                            // storage-bounded read, no overflow here
Ok(tensor)

data/src/tensor.rs, uninitialized_aligned_dt:

let bytes = shape.iter().cloned().product::<usize>() * dt.size_of();  // (3) wraps to the same small value
let storage = ... Blob::new_for_size_and_align(bytes, alignment) ...;
...
tensor.update_strides_and_len();                                     // len = product(shape), wraps, no clamp

The three quantities — the consistency-check LHS (2), the allocation (3), and the reported len — are all the same wrapped product(shape)*size_of, so they stay mutually consistent and the consistency check at (2) cannot catch the overflow. data_size_bytes is a u32, so the attacker simply sets it to the wrapped value.

Corruption sink — data/src/tensor.rs::as_slice_unchecked (and data/src/tensor/plain_view.rs::as_slice_unchecked):

if self.storage.byte_len() == 0 { &[] }
else { std::slice::from_raw_parts(self.as_ptr_unchecked(), self.len()) }  // len = 2^61 over a 56-byte alloc

The only guard is byte_len() == 0. A small non-zero allocation defeats it and yields an unsound oversized slice.

Witness (F64)

dims          = [33955849, 7005787, 359, 3, 3, 3]   (rank 6, each <= u32::MAX)
product(shape)= 2_305_843_009_213_693_959 = 2^61 + 7
bits_per_item = 64 (F64), item_type = 0, item_type_vendor = 0
data_size_bytes = 56            # == (2^61+7)*8 mod 2^64
  • len * (bits/8) mod 2^64 = (2^61+7)*8 mod 2^64 = 56 == data_size_bytes → consistency check passes.
  • allocation = (2^61+7)*8 mod 2^64 = 56 bytes (7 × F64).
  • reported len = 2^61+7 elements.

Only the is_copy() numeric arms (F16/F32/F64/int, and likely the complex arms) are exploitable. F64 is the cleanest (bits/8 divides evenly). The bool, String, and block-quant paths are each guarded by an independent mechanism (size_of==1 prevents byte/element divergence; String bails on a missing num_traits::Zero impl; block-quant has its own ensure!(expected_len == data_size_bytes) and uses non-plain Exotic storage).

Reachability (load-time, public API)

nnef().model_for_read(tar)
  -> proto_model_for_read                       nnef/src/framework.rs:303
    -> DatLoader.try_load (any *.dat)            nnef/src/resource.rs:97   (default loader, framework.rs:33)
      -> read_tensor -> Ok(Tensor{len=2^61+7, storage=56B})   nnef/src/tensors.rs:61
  -> into_typed_model -> variable() fragment     nnef/src/ops/nnef/deser.rs:74
       ensure!(tensor.shape() == &*shape)        deser.rs:122  (attacker matches shape in graph.nnef -> passes)
    -> Const::new -> wire_node                   core/src/model/typed.rs:67
      -> Const::output_facts                     core/src/ops/konst.rs:54
        -> TypedFact::try_from                   core/src/model/fact.rs:459
          -> Tensor::as_uniform -> is_uniform_t::<f64>   data/src/tensor.rs:1099
            -> as_slice_unchecked::<f64>         data/src/tensor.rs:1044
              -> from_raw_parts(ptr, 2^61+7) over 56-byte buffer -> OOB READ

No shape-vs-storage re-validation exists anywhere on this path (proto.validate() checks only the AST; Const::new checks only is_plain; check_for_access checks only the datum type; even the safe PlainView::as_slice does from_raw_parts(ptr, self.len) with no length guard).

Execution (proof of concept)

Reproduced against the crate at the affected revision, --release, x86_64-linux. Three scenarios:

  1. Direct read_tensor — feed the crafted 128-byte header + 56-byte payload:
  2. read_tensor -> Ok, shape=[33955849,7005787,359,3,3,3], len()=2305843009213693959, as_bytes().len()=56, as_slice::<f64>().len()=2305843009213693959.
  3. s[7] (first element past the 56-byte allocation) returns 0x0000000000000041 → heap OOB read (adjacent-heap disclosure).
  4. s[1<<40] → SIGSEGV (signal 11).
  5. Public load API — build a malicious .nnef.tar (graph.nnef with variable(label='weights', shape=[...]) + weights.dat) and call nnef().model_for_read():
  6. returns Ok with one Const node, out[0].fact.uniform=Some(...), len()=2305843009213693959 over a 56-byte buffer → confirms as_uniform/is_uniform_t/as_slice_unchecked performed an OOB read on load (bounded over-read here because is_uniform's .all() short-circuits on the uniform 0x41 payload).
  7. Optimized graph — same archive but the const is consumed (output = mul(weights, weights)), then into_optimized / run:
  8. Does not crash. With both a uniform (0x41×56) and a non-uniform (0..56) payload, into_optimized const-folds mul(const, const) to a single node without a full-length materialization of the oversized const, and run completes. A reliable arbitrary-length crash through a normal optimized graph was therefore NOT demonstrated; the always-on primitive is the bounded load-time over-read (scenario 2), and the wild-slice SIGSEGV is shown via direct access (scenario 1).

Runnable PoC sources are available to the maintainers on request.

Detection

  • Static: flag *.iter().product::<usize>() over externally-controlled dimensions without checked_*/try_into, especially when the result feeds an allocation and a separately-tracked len.
  • Runtime / fleet: crash telemetry showing SIGSEGV inside is_uniform_t / from_raw_parts during NNEF model load; an ASAN build flags heap-buffer-overflow READ in read_tensor→as_uniform.
  • Input filter (compensating): reject NNEF .dat tensors where product(dims) overflows u64, or where product(dims) * size_of(dt) != data_size_bytes computed in checked arithmetic, before constructing the tensor.
  • YARA-ish heuristic for .dat blobs: NNEF magic 4E EF 01 00, rank<=8, and any dim >= 0x10000 whose checked product with the others overflows.

Mitigation (suggested fix)

In read_tensor, compute the element count and byte size with checked arithmetic and reject on overflow, mirroring the guard already present on the block-quant path (ensure!(expected_len == data_size_bytes) added in eacd13ccb):

let len = shape.iter().try_fold(1usize, |a, &d| a.checked_mul(d))
    .context("tensor shape product overflows usize")?;
let byte_size = len.checked_mul(dt.size_of())
    .context("tensor byte size overflows usize")?;
ensure!(byte_size == header.data_size_bytes as usize, "shape/len vs data_size_bytes mismatch");

Defense in depth: make Tensor::uninitialized_aligned_dt reject when product(shape)*size_of overflows, and add a len * size_of == storage.byte_len() invariant check in the as_slice* accessors (or at Tensor construction) so a len/storage mismatch can never reach from_raw_parts.

Mapping: CWE-190, CWE-125; mitigations align with input validation (OWASP ASVS V5) and safe integer handling (CERT INT32-C analogue).

Prior art / why this is not already fixed

  • eacd13ccb (2026-03-23, "Add blob-size validation to BlockQuantStorage constructors") added overflow/blob-size validation only to the block-quant path; the dense DatLoader/read_tensor path was left unguarded. The maintainers fixed the sibling and missed this one.
  • PR #745 ("Fix UB by creating uninit Tensors with a non-null pointer") is a different UB (null base pointer on zero-length slices) in the same module family.
  • No CVE / RustSec / GHSA / OSV / Huntr entry matches this bug; last change to nnef/src/tensors.rs predates HEAD and added no overflow guard to the dense path.

Reported by: s1ko (s1ko@riseup.net · github.com/s1ko)

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tract-nnef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tract-nnef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tract-nnef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T15:05:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "- **Component:** `tract-nnef` (`nnef/src/tensors.rs::read_tensor`) + `tract-data` (`data/src/tensor.rs`)\n- **Affected versions:** `\u003c 0.21.16`, `0.22.0`\u2013`0.22.2`, `0.23.0`\u2013`0.23.1` \u2014 the dense `DatLoader` path was unguarded across all three release lines; patched in 0.21.16 / 0.22.2 / 0.23.1\n- **Class:** CWE-190 (integer overflow) \u2192 CWE-125 (out-of-bounds read)\n- **Trigger:** loading a crafted NNEF model archive (`*.nnef.tgz` / `*.nnef.tar` / dir) via the public `tract_nnef::nnef().model_for_path` / `model_for_read`\n- **Impact:** `read_tensor` returns a memory-unsafe tensor (reported `len` 2^61 over a 56-byte heap allocation). Always-on primitive: a **bounded heap out-of-bounds read** during model build (`as_uniform`), an adjacent-heap information-disclosure reachable via the public load API. The resulting slice is an unsound `from_raw_parts(ptr, 2^61)` that **SIGSEGVs (DoS)** on any access past the mapped region (demonstrated by direct access). No out-of-bounds write and no RCE were achieved \u2014 tract\u0027s const-folding/`as_uniform` fast-paths fold simple consuming graphs without the full read.\n- **Severity:** Medium\n\n## Summary\n\n`read_tensor` builds a tensor `shape` from attacker-controlled 32-bit dimensions and computes the element count `len = product(shape)` and the byte allocation `product(shape) * size_of(dt)` with **unchecked `usize` arithmetic**. In `--release` (no `overflow-checks`), both products wrap modulo 2^64. An attacker chooses dimensions so that the wrapped products collapse to a small value that satisfies the header consistency check, while the *true* element count remains astronomically large. `read_tensor` returns `Ok` with a `Tensor` whose reported `len` (e.g. 2^61+7) is far larger than its backing heap allocation (e.g. 56 bytes). The unchecked slice accessor `as_slice_unchecked` (`from_raw_parts(ptr, self.len)`) then produces a slice spanning ~18 exabytes over a 56-byte buffer. The out-of-bounds read fires automatically during model build (no inference required), reachable through the default `DatLoader` resource loader.\n\n## Root cause\n\n`nnef/src/tensors.rs`, `read_tensor`:\n\n```\nlet shape: TVec\u003cusize\u003e = header.dims[0..header.rank as usize].iter().map(|d| *d as _).collect();\nlet len = shape.iter().product::\u003cusize\u003e();                       // (1) unchecked, wraps\n...\n} else if header.bits_per_item != u32::MAX\n    \u0026\u0026 len * (header.bits_per_item as usize / 8) != header.data_size_bytes as usize  // (2) wrapped == u32\n{\n    bail!(...);\n}\n...\nlet mut tensor = unsafe { Tensor::uninitialized_dt(dt, \u0026shape)? };   // (3) alloc off the same wrapped product\n...\nreader.read_exact(plain.as_bytes_mut())?;                            // storage-bounded read, no overflow here\nOk(tensor)\n```\n\n`data/src/tensor.rs`, `uninitialized_aligned_dt`:\n\n```\nlet bytes = shape.iter().cloned().product::\u003cusize\u003e() * dt.size_of();  // (3) wraps to the same small value\nlet storage = ... Blob::new_for_size_and_align(bytes, alignment) ...;\n...\ntensor.update_strides_and_len();                                     // len = product(shape), wraps, no clamp\n```\n\nThe three quantities \u2014 the consistency-check LHS `(2)`, the allocation `(3)`, and the reported `len` \u2014 are all the same wrapped `product(shape)*size_of`, so they stay mutually consistent and **the consistency check at `(2)` cannot catch the overflow**. `data_size_bytes` is a `u32`, so the attacker simply sets it to the wrapped value.\n\nCorruption sink \u2014 `data/src/tensor.rs::as_slice_unchecked` (and `data/src/tensor/plain_view.rs::as_slice_unchecked`):\n\n```\nif self.storage.byte_len() == 0 { \u0026[] }\nelse { std::slice::from_raw_parts(self.as_ptr_unchecked(), self.len()) }  // len = 2^61 over a 56-byte alloc\n```\n\nThe only guard is `byte_len() == 0`. A small **non-zero** allocation defeats it and yields an unsound oversized slice.\n\n## Witness (F64)\n\n```\ndims          = [33955849, 7005787, 359, 3, 3, 3]   (rank 6, each \u003c= u32::MAX)\nproduct(shape)= 2_305_843_009_213_693_959 = 2^61 + 7\nbits_per_item = 64 (F64), item_type = 0, item_type_vendor = 0\ndata_size_bytes = 56            # == (2^61+7)*8 mod 2^64\n```\n\n- `len * (bits/8) mod 2^64 = (2^61+7)*8 mod 2^64 = 56 == data_size_bytes` \u2192 consistency check passes.\n- allocation = `(2^61+7)*8 mod 2^64 = 56` bytes (7 \u00d7 F64).\n- reported `len` = `2^61+7` elements.\n\nOnly the `is_copy()` numeric arms (F16/F32/F64/int, and likely the `complex` arms) are exploitable. F64 is the cleanest (`bits/8` divides evenly). The `bool`, `String`, and block-quant paths are each guarded by an independent mechanism (size_of==1 prevents byte/element divergence; `String` bails on a missing `num_traits::Zero` impl; block-quant has its own `ensure!(expected_len == data_size_bytes)` and uses non-plain `Exotic` storage).\n\n## Reachability (load-time, public API)\n\n```\nnnef().model_for_read(tar)\n  -\u003e proto_model_for_read                       nnef/src/framework.rs:303\n    -\u003e DatLoader.try_load (any *.dat)            nnef/src/resource.rs:97   (default loader, framework.rs:33)\n      -\u003e read_tensor -\u003e Ok(Tensor{len=2^61+7, storage=56B})   nnef/src/tensors.rs:61\n  -\u003e into_typed_model -\u003e variable() fragment     nnef/src/ops/nnef/deser.rs:74\n       ensure!(tensor.shape() == \u0026*shape)        deser.rs:122  (attacker matches shape in graph.nnef -\u003e passes)\n    -\u003e Const::new -\u003e wire_node                   core/src/model/typed.rs:67\n      -\u003e Const::output_facts                     core/src/ops/konst.rs:54\n        -\u003e TypedFact::try_from                   core/src/model/fact.rs:459\n          -\u003e Tensor::as_uniform -\u003e is_uniform_t::\u003cf64\u003e   data/src/tensor.rs:1099\n            -\u003e as_slice_unchecked::\u003cf64\u003e         data/src/tensor.rs:1044\n              -\u003e from_raw_parts(ptr, 2^61+7) over 56-byte buffer -\u003e OOB READ\n```\n\nNo shape-vs-storage re-validation exists anywhere on this path (`proto.validate()` checks only the AST; `Const::new` checks only `is_plain`; `check_for_access` checks only the datum type; even the *safe* `PlainView::as_slice` does `from_raw_parts(ptr, self.len)` with no length guard).\n\n## Execution (proof of concept)\n\nReproduced against the crate at the affected revision, `--release`, x86_64-linux. Three scenarios:\n\n1. **Direct `read_tensor`** \u2014 feed the crafted 128-byte header + 56-byte payload:\n   - `read_tensor -\u003e Ok`, `shape=[33955849,7005787,359,3,3,3]`, `len()=2305843009213693959`, `as_bytes().len()=56`, `as_slice::\u003cf64\u003e().len()=2305843009213693959`.\n   - `s[7]` (first element past the 56-byte allocation) returns `0x0000000000000041` \u2192 **heap OOB read** (adjacent-heap disclosure).\n   - `s[1\u003c\u003c40]` \u2192 **SIGSEGV** (signal 11).\n2. **Public load API** \u2014 build a malicious `.nnef.tar` (`graph.nnef` with `variable(label=\u0027weights\u0027, shape=[...])` + `weights.dat`) and call `nnef().model_for_read()`:\n   - returns `Ok` with one `Const` node, `out[0].fact.uniform=Some(...)`, `len()=2305843009213693959` over a 56-byte buffer \u2192 confirms `as_uniform`/`is_uniform_t`/`as_slice_unchecked` performed an **OOB read on load** (bounded over-read here because `is_uniform`\u0027s `.all()` short-circuits on the uniform `0x41` payload).\n3. **Optimized graph** \u2014 same archive but the const is consumed (`output = mul(weights, weights)`), then `into_optimized` / `run`:\n   - **Does not crash.** With both a uniform (`0x41\u00d756`) and a non-uniform (`0..56`) payload, `into_optimized` const-folds `mul(const, const)` to a single node **without a full-length materialization** of the oversized const, and `run` completes. A reliable arbitrary-length crash through a *normal optimized graph* was therefore NOT demonstrated; the always-on primitive is the bounded load-time over-read (scenario 2), and the wild-slice SIGSEGV is shown via direct access (scenario 1).\n\nRunnable PoC sources are available to the maintainers on request.\n\n## Detection\n\n- **Static:** flag `*.iter().product::\u003cusize\u003e()` over externally-controlled dimensions without `checked_*`/`try_into`, especially when the result feeds an allocation and a separately-tracked `len`.\n- **Runtime / fleet:** crash telemetry showing SIGSEGV inside `is_uniform_t` / `from_raw_parts` during NNEF model load; an ASAN build flags `heap-buffer-overflow READ` in `read_tensor`\u2192`as_uniform`.\n- **Input filter (compensating):** reject NNEF `.dat` tensors where `product(dims)` overflows `u64`, or where `product(dims) * size_of(dt) != data_size_bytes` computed in **checked** arithmetic, before constructing the tensor.\n- **YARA-ish heuristic for `.dat` blobs:** NNEF magic `4E EF 01 00`, `rank\u003c=8`, and any `dim \u003e= 0x10000` whose checked product with the others overflows.\n\n## Mitigation (suggested fix)\n\nIn `read_tensor`, compute the element count and byte size with checked arithmetic and reject on overflow, mirroring the guard already present on the block-quant path (`ensure!(expected_len == data_size_bytes)` added in `eacd13ccb`):\n\n```\nlet len = shape.iter().try_fold(1usize, |a, \u0026d| a.checked_mul(d))\n    .context(\"tensor shape product overflows usize\")?;\nlet byte_size = len.checked_mul(dt.size_of())\n    .context(\"tensor byte size overflows usize\")?;\nensure!(byte_size == header.data_size_bytes as usize, \"shape/len vs data_size_bytes mismatch\");\n```\n\nDefense in depth: make `Tensor::uninitialized_aligned_dt` reject when `product(shape)*size_of` overflows, and add a `len * size_of == storage.byte_len()` invariant check in the `as_slice*` accessors (or at `Tensor` construction) so a `len`/storage mismatch can never reach `from_raw_parts`.\n\nMapping: CWE-190, CWE-125; mitigations align with input validation (OWASP ASVS V5) and safe integer handling (CERT INT32-C analogue).\n\n## Prior art / why this is not already fixed\n\n- `eacd13ccb` (2026-03-23, \"Add blob-size validation to BlockQuantStorage constructors\") added overflow/blob-size validation **only to the block-quant path**; the dense `DatLoader`/`read_tensor` path was left unguarded. The maintainers fixed the sibling and missed this one.\n- PR #745 (\"Fix UB by creating uninit Tensors with a non-null pointer\") is a *different* UB (null base pointer on zero-length slices) in the same module family.\n- No CVE / RustSec / GHSA / OSV / Huntr entry matches this bug; last change to `nnef/src/tensors.rs` predates HEAD and added no overflow guard to the dense path.\n\n---\n\nReported by: s1ko (s1ko@riseup.net \u00b7 github.com/s1ko)",
  "id": "GHSA-x5mv-8wgw-29hg",
  "modified": "2026-06-18T15:05:23Z",
  "published": "2026-06-18T15:05:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sonos/tract/security/advisories/GHSA-x5mv-8wgw-29hg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sonos/tract"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "tract-nnef: integer overflow in NNEF `.dat` tensor parser yields an out-of-bounds read on model load"
}

GHSA-X5PQ-PM4R-VX73

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-08-06 00:00
VLAI
Details

A flaw was found in libwebp in versions before 1.0.1. An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-25012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-21T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in libwebp in versions before 1.0.1. An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.",
  "id": "GHSA-x5pq-pm4r-vx73",
  "modified": "2022-08-06T00:00:44Z",
  "published": "2022-05-24T19:02:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25012"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9123"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1956922"
    },
    {
      "type": "WEB",
      "url": "https://chromium.googlesource.com/webm/libwebp/+/95fd65070662e01cc9170c4444f5c0859a710097"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20211112-0001"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5PR-3426-W9PH

Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-01-07 18:30
VLAI
Details

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

f2fs: fix to avoid out-of-boundary access in devs.path

  • touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123
  • truncate -s $((102410241024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123
  • touch /mnt/f2fs/file
  • truncate -s $((102410241024)) /mnt/f2fs/file
  • mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file
  • mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop

[16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices

If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path.

struct f2fs_dev_info { ... char path[MAX_PATH_LEN]; ... };

Let's add one byte space for sbi->devs.path[] to store null character of device path string.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-38652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T16:15:40Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-boundary access in devs.path\n\n- touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123\n- truncate -s $((1024*1024*1024)) \\\n  /mnt/f2fs/012345678901234567890123456789012345678901234567890123\n- touch /mnt/f2fs/file\n- truncate -s $((1024*1024*1024)) /mnt/f2fs/file\n- mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\\n  -c /mnt/f2fs/file\n- mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\\n  /mnt/f2fs/loop\n\n[16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\\xff\\x01,      511,        0 -    3ffff\n[16937.192268] F2FS-fs (loop0): Failed to find devices\n\nIf device path length equals to MAX_PATH_LEN, sbi-\u003edevs.path[] may\nnot end up w/ null character due to path array is fully filled, So\naccidently, fields locate after path[] may be treated as part of\ndevice path, result in parsing wrong device path.\n\nstruct f2fs_dev_info {\n...\n\tchar path[MAX_PATH_LEN];\n...\n};\n\nLet\u0027s add one byte space for sbi-\u003edevs.path[] to store null\ncharacter of device path string.",
  "id": "GHSA-x5pr-3426-w9ph",
  "modified": "2026-01-07T18:30:21Z",
  "published": "2025-08-22T18:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38652"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b1efa5f0e878745e94a98022e8edc675a87d78e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1cf1ff15f262e8baf12201b270b6a79f9d119b2d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/345fc8d1838f3f8be7c8ed08d86a13dedef67136"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3466721f06edff834f99d9f49f23eabc6b2cb78e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5661998536af52848cc4d52a377e90368196edea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/666b7cf6ac9aa074b8319a2b68cba7f2c30023f0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/70849d33130a2cf1d6010069ed200669c8651fbd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/755427093e4294ac111c3f9e40d53f681a0fbdaa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dc0172c74bd9edaee7bea2ebb35f3dbd37a8ae80"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5Q2-QQWH-X9RV

Vulnerability from github – Published: 2024-07-29 09:36 – Updated: 2025-11-04 00:30
VLAI
Details

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

tun: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tun_xdp_one() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tun_xdp_one-->eth_type_trans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tun_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP.

This is to drop any frame shorter than the Ethernet header size just like how tun_get_user() does.

CVE: CVE-2024-41091

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-41091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-29T07:15:07Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntun: add missing verification for short frame\n\nThe cited commit missed to check against the validity of the frame length\nin the tun_xdp_one() path, which could cause a corrupted skb to be sent\ndownstack. Even before the skb is transmitted, the\ntun_xdp_one--\u003eeth_type_trans() may access the Ethernet header although it\ncan be less than ETH_HLEN. Once transmitted, this could either cause\nout-of-bound access beyond the actual length, or confuse the underlayer\nwith incorrect or inconsistent header length in the skb metadata.\n\nIn the alternative path, tun_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted for\nIFF_TAP.\n\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tun_get_user() does.\n\nCVE: CVE-2024-41091",
  "id": "GHSA-x5q2-qqwh-x9rv",
  "modified": "2025-11-04T00:30:59Z",
  "published": "2024-07-29T09:36:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41091"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/049584807f1d797fc3078b68035450a9769eb5c3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/32b0aaba5dbc85816898167d9b5d45a22eae82e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/589382f50b4a5d90d16d8bc9dcbc0e927a3e39b2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6100e0237204890269e3f934acfc50d35fd6f319"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8418f55302fa1d2eeb73e16e345167e545c598a5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a9d1c27e2ee3b0ea5d40c105d6e728fc114470bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad6b3f622ccfb4bfedfa53b6ebd91c3d1d04f146"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d5ad89b7d01ed4e66fd04734fc63d6e78536692a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5V6-PX87-HPFM

Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31
VLAI
Details

PDF-XChange Editor U3D File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-26532.

Severity
3.3 (Low)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-6643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-25T22:15:21Z",
    "severity": "LOW"
  },
  "details": "PDF-XChange Editor U3D File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.\n\nThe specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-26532.",
  "id": "GHSA-x5v6-px87-hpfm",
  "modified": "2025-06-26T21:31:14Z",
  "published": "2025-06-26T21:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6643"
    },
    {
      "type": "WEB",
      "url": "https://www.pdf-xchange.com/support/security-bulletins.html"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-428"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5VR-7M95-28CM

Vulnerability from github – Published: 2022-07-19 00:00 – Updated: 2022-07-24 00:00
VLAI
Details

This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader 11.2.1.53537. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of ADBC objects. By performing actions in JavaScript, an attacker can trigger a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-16981.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-34875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-18T19:15:00Z",
    "severity": "LOW"
  },
  "details": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader 11.2.1.53537. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of ADBC objects. By performing actions in JavaScript, an attacker can trigger a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-16981.",
  "id": "GHSA-x5vr-7m95-28cm",
  "modified": "2022-07-24T00:00:35Z",
  "published": "2022-07-19T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34875"
    },
    {
      "type": "WEB",
      "url": "https://www.foxit.com/support/security-bulletins.html"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-950"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5WJ-5P39-RP5W

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

Delta Electronics Delta Industrial Automation PMSoft v2.11 or prior has an out-of-bounds read vulnerability that can be executed when processing project files, which may allow an attacker to read confidential information.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-14824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-27T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Delta Electronics Delta Industrial Automation PMSoft v2.11 or prior has an out-of-bounds read vulnerability that can be executed when processing project files, which may allow an attacker to read confidential information.",
  "id": "GHSA-x5wj-5p39-rp5w",
  "modified": "2022-05-13T01:34:24Z",
  "published": "2022-05-13T01:34:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14824"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-270-04"
    },
    {
      "type": "WEB",
      "url": "http://www.deltaww.com/services/DownloadCenter2.aspx?secID=8\u0026pid=2\u0026tid=0\u0026CID=06\u0026itemID=060301\u0026typeID=1\u0026downloadID=,\u0026title=--%20Select%20Product%20Series%20--\u0026dataType=8;\u0026check=1\u0026hl=en-US"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105409"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X62V-M8X2-XX3Q

Vulnerability from github – Published: 2025-03-11 12:30 – Updated: 2025-03-11 12:30
VLAI
Details

A vulnerability has been identified in Teamcenter Visualization V14.3 (All versions < V14.3.0.13), Teamcenter Visualization V2312 (All versions < V2312.0009), Teamcenter Visualization V2406 (All versions < V2406.0007), Teamcenter Visualization V2412 (All versions < V2412.0002), Tecnomatix Plant Simulation V2302 (All versions < V2302.0021), Tecnomatix Plant Simulation V2404 (All versions < V2404.0010). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted WRL files. This could allow an attacker to execute code in the context of the current process.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-27438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T10:15:19Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Teamcenter Visualization V14.3 (All versions \u003c V14.3.0.13), Teamcenter Visualization V2312 (All versions \u003c V2312.0009), Teamcenter Visualization V2406 (All versions \u003c V2406.0007), Teamcenter Visualization V2412 (All versions \u003c V2412.0002), Tecnomatix Plant Simulation V2302 (All versions \u003c V2302.0021), Tecnomatix Plant Simulation V2404 (All versions \u003c V2404.0010). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted WRL files.\nThis could allow an attacker to execute code in the context of the current process.",
  "id": "GHSA-x62v-m8x2-xx3q",
  "modified": "2025-03-11T12:30:59Z",
  "published": "2025-03-11T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27438"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-050438.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/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"
    }
  ]
}

GHSA-X63J-V2J2-M8FV

Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-23 21:31
VLAI
Details

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

ALSA: usb-audio: Use correct version for UAC3 header validation

The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields.

The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-23318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T11:16:28Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Use correct version for UAC3 header validation\n\nThe entry of the validators table for UAC3 AC header descriptor is\ndefined with the wrong protocol version UAC_VERSION_2, while it should\nhave been UAC_VERSION_3.  This results in the validator never matching\nfor actual UAC3 devices (protocol == UAC_VERSION_3), causing their\nheader descriptors to bypass validation entirely.  A malicious USB\ndevice presenting a truncated UAC3 header could exploit this to cause\nout-of-bounds reads when the driver later accesses unvalidated\ndescriptor fields.\n\nThe bug was introduced in the same commit as the recently fixed UAC3\nfeature unit sub-type typo, and appears to be from the same copy-paste\nerror when the UAC3 section was created from the UAC2 section.",
  "id": "GHSA-x63j-v2j2-m8fv",
  "modified": "2026-04-23T21:31:16Z",
  "published": "2026-03-25T12:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23318"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0dcd1ed96c03459cf14706885c9dd3c1fd8bd29f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e5753ff4c2e86aa88516f97a224c90a3d0b133e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/499ffd15b00dc91ac95c28f76959dfb5cdcc84d5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/54f9d645a5453d0bfece0c465d34aaf072ea99fa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82a7d0a1b88798de1a609130080ce0c65dd869e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8307d93e63d5f54ef10412d4db2dd551e920dee4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0c6ae2ea84528f198bf7fd0117f12fd0cf6d7cc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3904ca40515272681ae61ad6f561c24f190957f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X63V-XW79-MW5J

Vulnerability from github – Published: 2023-01-06 21:30 – Updated: 2025-04-10 15:31
VLAI
Details

The HW_KEYMASTER module has a problem in releasing memory.Successful exploitation of this vulnerability may result in out-of-bounds memory access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-46867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-06T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "The HW_KEYMASTER module has a problem in releasing memory.Successful exploitation of this vulnerability may result in out-of-bounds memory access.",
  "id": "GHSA-x63v-xw79-mw5j",
  "modified": "2025-04-10T15:31:31Z",
  "published": "2023-01-06T21:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46867"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/1"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202301-0000001435541166"
    }
  ],
  "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"
    }
  ]
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
Mitigation
Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

CAPEC-540: Overread Buffers

An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution.

← Back to the CWE list