GHSA-J842-XGM4-WF88

Vulnerability from github – Published: 2025-11-21 18:03 – Updated: 2026-06-06 00:34
VLAI
Summary
MLX has Wild Pointer Dereference in load_gguf()
Details

Summary

Segmentation fault in mlx::core::load_gguf() when loading malicious GGUF files. Untrusted pointer from external gguflib library is dereferenced without validation, causing application crash.

Environment: - OS: Ubuntu 20.04.6 LTS - Compiler: Clang 19.1.7

Vulnerability

Location: mlx/io/gguf.cpp - Function extract_tensor_data() at lines 59-79 - Vulnerable memcpy at lines 64-67 - Called from load_arrays() at line 177

The Bug:

std::tuple<allocator::Buffer, Dtype> extract_tensor_data(gguf_tensor* tensor) {
  std::optional<Dtype> equivalent_dtype = gguf_type_to_dtype(tensor->type);
  if (equivalent_dtype.has_value()) {
    allocator::Buffer buffer = allocator::malloc(tensor->bsize);
    memcpy(
        buffer.raw_ptr(),
        tensor->weights_data,  // untrusted pointer from gguflib
        tensor->num_weights * equivalent_dtype.value().size());
    return {buffer, equivalent_dtype.value()};
  }
  // ...
}

Possible Fix

std::tuple<allocator::Buffer, Dtype> extract_tensor_data(gguf_tensor* tensor) {
  std::optional<Dtype> equivalent_dtype = gguf_type_to_dtype(tensor->type);
  if (equivalent_dtype.has_value()) {
    // FIX: Validate pointer
    if (!tensor->weights_data) {
      throw std::runtime_error("[load_gguf] NULL tensor data pointer");
    }

    allocator::Buffer buffer = allocator::malloc(tensor->bsize);
    memcpy(
        buffer.raw_ptr(),
        tensor->weights_data,
        tensor->num_weights * equivalent_dtype.value().size());
    return {buffer, equivalent_dtype.value()};
  }
  // ...
}

PoC

# Install MLX
pip install mlx

python3 -c "import mlx.core as mx; mx.load('exploit.gguf', format='gguf')"

Download the poc file there, or let me know how I can send it to you.

AddressSanitizer Output (with instrumented build):

AddressSanitizer:DEADLYSIGNAL
=================================================================
==5855==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc432f64bc0 (pc 0x7fc430841c12 bp 0x7ffc04847ab0 sp 0x7ffc04847268 T0)
==5855==The signal is caused by a READ memory access.
    #0 0x7fc430841c12  /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:312
    #1 0x55aac829756b in __asan_memcpy (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x9ef56b) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)
    #2 0x55aacaa6e8dc in mlx::core::extract_tensor_data(gguf_tensor*) /home/user1/mlx/mlx/io/gguf.cpp:64:5
    #3 0x55aacaa773fc in mlx::core::load_arrays[abi:cxx11](gguf_ctx*) /home/user1/mlx/mlx/io/gguf.cpp:226:35
    #4 0x55aacaa782a9 in mlx::core::load_gguf(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, std::variant<std::monostate, mlx::core::Stream, mlx::core::Device>) /home/user1/mlx/mlx/io/gguf.cpp:250:17
    #5 0x55aac82dc696 in LLVMFuzzerTestOneInput /home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf.cpp:49:19
    #6 0x55aac81e25c6 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x93a5c6) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)
    #7 0x55aac81cc738 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x924738) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)
    #8 0x55aac81d220a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x92a20a) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)
    #9 0x55aac81fbb82 in main (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x953b82) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)
    #10 0x7fc4307aa082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #11 0x55aac81c73ed in _start (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x91f3ed) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)

==5855==Register values:
rax = 0x0000502000000098  rbx = 0xfafafafa0000fa00  rcx = 0x00000a047fff8013  rdx = 0x0000000000000008
rdi = 0x0000502000000098  rsi = 0x00007fc432f64bc0  rbp = 0x00007ffc04847ab0  rsp = 0x00007ffc04847268
 r8 = 0x00000a0400000013   r9 = 0x0000000000000000  r10 = 0x00000a0400000013  r11 = 0x0000000000000000
r12 = 0x00000a047fff8010  r13 = 0xffffffffffffffc7  r14 = 0x00007fc42dd00280  r15 = 0x00000ff885ba0050
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:312
==5855==ABORTING

Impact

  • Attack vector: Malicious GGUF file (model weights, typically from untrusted sources)
  • Affects: MLX users on all platforms who call the vulnerable method with unsanitized input.
  • Result: Segmentation fault (uncatchable by exception handlers)

Credits:

  • Markiyan Melnyk (ARIMLABS)
  • Mykyta Mudryi (ARIMLABS)
  • Markiyan Chaklosh (ARIMLABS)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.29.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "mlx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.29.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-21T18:03:20Z",
    "nvd_published_at": "2025-11-21T19:16:02Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nSegmentation fault in `mlx::core::load_gguf()` when loading malicious GGUF files. Untrusted pointer from external gguflib library is dereferenced without validation, causing application crash.\n\nEnvironment:\n- OS: Ubuntu 20.04.6 LTS\n- Compiler: Clang 19.1.7\n\n## Vulnerability\n\n**Location**: `mlx/io/gguf.cpp`\n- Function `extract_tensor_data()` at lines 59-79\n- Vulnerable memcpy at lines 64-67\n- Called from `load_arrays()` at line 177\n\n**The Bug**:\n```cpp\nstd::tuple\u003callocator::Buffer, Dtype\u003e extract_tensor_data(gguf_tensor* tensor) {\n  std::optional\u003cDtype\u003e equivalent_dtype = gguf_type_to_dtype(tensor-\u003etype);\n  if (equivalent_dtype.has_value()) {\n    allocator::Buffer buffer = allocator::malloc(tensor-\u003ebsize);\n    memcpy(\n        buffer.raw_ptr(),\n        tensor-\u003eweights_data,  // untrusted pointer from gguflib\n        tensor-\u003enum_weights * equivalent_dtype.value().size());\n    return {buffer, equivalent_dtype.value()};\n  }\n  // ...\n}\n```\n\n## Possible Fix\n\n```cpp\nstd::tuple\u003callocator::Buffer, Dtype\u003e extract_tensor_data(gguf_tensor* tensor) {\n  std::optional\u003cDtype\u003e equivalent_dtype = gguf_type_to_dtype(tensor-\u003etype);\n  if (equivalent_dtype.has_value()) {\n    // FIX: Validate pointer\n    if (!tensor-\u003eweights_data) {\n      throw std::runtime_error(\"[load_gguf] NULL tensor data pointer\");\n    }\n\n    allocator::Buffer buffer = allocator::malloc(tensor-\u003ebsize);\n    memcpy(\n        buffer.raw_ptr(),\n        tensor-\u003eweights_data,\n        tensor-\u003enum_weights * equivalent_dtype.value().size());\n    return {buffer, equivalent_dtype.value()};\n  }\n  // ...\n}\n```\n\n## PoC\n\n```bash\n# Install MLX\npip install mlx\n\npython3 -c \"import mlx.core as mx; mx.load(\u0027exploit.gguf\u0027, format=\u0027gguf\u0027)\"\n```\n\nDownload the poc file [there](https://drive.google.com/file/d/1t9Z2RJGn-oHmluKWebU077UWSMGXeuVp/view?usp=sharing), or let me know how I can send it to you.\n\n**AddressSanitizer Output (with instrumented build)**:\n```\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==5855==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc432f64bc0 (pc 0x7fc430841c12 bp 0x7ffc04847ab0 sp 0x7ffc04847268 T0)\n==5855==The signal is caused by a READ memory access.\n    #0 0x7fc430841c12  /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:312\n    #1 0x55aac829756b in __asan_memcpy (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x9ef56b) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n    #2 0x55aacaa6e8dc in mlx::core::extract_tensor_data(gguf_tensor*) /home/user1/mlx/mlx/io/gguf.cpp:64:5\n    #3 0x55aacaa773fc in mlx::core::load_arrays[abi:cxx11](gguf_ctx*) /home/user1/mlx/mlx/io/gguf.cpp:226:35\n    #4 0x55aacaa782a9 in mlx::core::load_gguf(std::__cxx11::basic_string\u003cchar, std::char_traits\u003cchar\u003e, std::allocator\u003cchar\u003e\u003e const\u0026, std::variant\u003cstd::monostate, mlx::core::Stream, mlx::core::Device\u003e) /home/user1/mlx/mlx/io/gguf.cpp:250:17\n    #5 0x55aac82dc696 in LLVMFuzzerTestOneInput /home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf.cpp:49:19\n    #6 0x55aac81e25c6 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x93a5c6) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n    #7 0x55aac81cc738 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x924738) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n    #8 0x55aac81d220a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x92a20a) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n    #9 0x55aac81fbb82 in main (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x953b82) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n    #10 0x7fc4307aa082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16\n    #11 0x55aac81c73ed in _start (/home/user1/mlx/fuzz/load_gguf/fuzz_load_gguf+0x91f3ed) (BuildId: 57467f1ce96052757daeef4b04739be7f23c5f1f)\n\n==5855==Register values:\nrax = 0x0000502000000098  rbx = 0xfafafafa0000fa00  rcx = 0x00000a047fff8013  rdx = 0x0000000000000008\nrdi = 0x0000502000000098  rsi = 0x00007fc432f64bc0  rbp = 0x00007ffc04847ab0  rsp = 0x00007ffc04847268\n r8 = 0x00000a0400000013   r9 = 0x0000000000000000  r10 = 0x00000a0400000013  r11 = 0x0000000000000000\nr12 = 0x00000a047fff8010  r13 = 0xffffffffffffffc7  r14 = 0x00007fc42dd00280  r15 = 0x00000ff885ba0050\nAddressSanitizer can not provide additional info.\nSUMMARY: AddressSanitizer: SEGV /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:312\n==5855==ABORTING\n```\n\n## Impact\n\n- **Attack vector**: Malicious GGUF file (model weights, typically from untrusted sources)\n- **Affects**: MLX users on all platforms who call the vulnerable method with unsanitized input.\n- **Result**: Segmentation fault (uncatchable by exception handlers)\n\n---\nCredits:\n\n- Markiyan Melnyk (ARIMLABS)\n- Mykyta Mudryi (ARIMLABS)\n- Markiyan Chaklosh (ARIMLABS)",
  "id": "GHSA-j842-xgm4-wf88",
  "modified": "2026-06-06T00:34:04Z",
  "published": "2025-11-21T18:03:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ml-explore/mlx/security/advisories/GHSA-j842-xgm4-wf88"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62609"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ml-explore/mlx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mlx/PYSEC-2025-139.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MLX has Wild Pointer Dereference in load_gguf()"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…