In OCaml through 4.14.3, Bigarray.reshape allows an integer overflow, and resultant reading of arbitrary memory, when untrusted data is processed.

In OCaml before 4.14.3 and 5.x before 5.4.1, a buffer over-read in Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from crafted Marshal data.

Summary

A critical buffer over-read vulnerability in OCaml's Marshal deserialization (runtime/intern.c) enables remote code execution through a multi-phase attack chain. The vulnerability stems from missing bounds validation in the readblock() function, which performs unbounded memcpy() operations using attacker-controlled lengths from malicious Marshal data.

Please note that Marshal is not type safe, and you have to be careful if you use the deserialization on untrusted input (due to type confusion, and remote code execution by design - you can use Marshal for code).

Affected functions: Marshal.fromchannel, Marshal.frombytes, Marshal.fromstring, Stdlib.inputvalue, Pervasives.inputvalue when reading data from an untrusted source.

Vulnerability Attack Vector

Corrupted or malicious marshaled data that causes undefined behaviour in the runtime system when unmarshaled. inputvalue should either fail cleanly or produce a well-formed OCaml object, without corrupting the runtime system.

Consequently, this excludes:

well-formed marshaled data that produces an OCaml object that is not of the type expected by the OCaml code and causes the Ocaml code to crash or misbehave

misuses of the OCaml runtime system by the program performing inputvalue, such as setting Debugger.functionplaceholder to the wrong function.

The former issue may be addressed at some point by validating the unmarshaled OCaml value against the expected type, using the functions from module Obj and some kind of run-time type description.

The latter issue is a bug in the program that unmarshals the data.

Fix

OCaml runtime

The OCaml runtime has been hardened with additional bounds checks. An exception is raised on bad input.

Third party libraries

Third party libraries that want to harden their custom Marshal deserialization code can follow the example fix for bigarrays from the standard library. There are new macros in custom.h called Wsizecustomdata and Bsizecustomdata that return the size in words or bytes of the allocated custom destination block. The deserializer needs to ensure it only writes data within those bounds.

This only needs to be done if the library defines a custom type in a C binding, and struct customoperations's deserialize field is not set to NULL or customdeserializedefault, and struct customoperations's fixedlength field is set to NULL or customfixedlengthdefault

Since Marshal.from and inputvalue remain unsafe to use, the fix for the OCaml runtime is released, and we wouldn't attempt to coordinate updating all deserialization functions in the ecosystem.

Timeline

- Nov 4th 2025: Discovery Date: Discovered first in OxCaml - Nov 5th 2025: First Disclosure Date (Jane Street Team): Emailed top maintainers, no response. - Nov 9th 2025: Second Disclosure Date (OCaml Team): Submitted to OCaml/ocaml GitHub Repo as a Security Advisory. - Nov 11th 2025: Emailed OCaml Security Mail List: Submitted to OCaml over email, responded asking for details. - Nov 11th 2025: Third Disclosure (OCaml Security Response Team): Submitted to ocaml/security-advisories GitHub Repo as a Security Advisory. - Dec 16th 2025: Initial patch is developed - Dec 17th 2025: Fuzz testing found further issues - Dec 24th 2025: Final patch for OCaml is developed - Dec 25th 2025: Fuzz testing couldn't find any further issues - Jan 2nd 2026: Patch got reviewed by OCaml maintainers - Jan 4th 2026: Benchmarking of the patch with good results - Jan 6th 2026: Reporter got contacted to confirm - Jan 25th 2026: Further related issues discovered by fuzzing - Feb 17th 2026: fixed OCaml releases are published, security advisory is published

Bug description

The bigarray module in all recent ocaml versions is capable of reading in serialized (marshalled) objects from a external source which is often used for network operations and interprocess communication.

byterun/bigarray.c

Line 458 in ea60609 C b->data = malloc(eltsize numelts);

A integer overflow vulnerability allows under certain circumstances an remote attacker to input a corrupt object and edit arbitrary addresses in the processes memory which leads over common techniques (in this take libc one gadget but any rop gadget or got table vector would work) to arbitrary memory access (!) and in the course also arbitrary code execution

Please check the writeup.pdf for more details !!

In variations of this the exploit is usable in all ocaml versions we tested no matter if compiled to binary or intepreted (!)

Steps to reproduce

Check out the attached archive and run the makefile (or use the precompile executable) the exploit can be run by executing exploit.py (python2.7 and pwntools are required) The last step of code execution is using a one-gadget attack technique and is specific to the glibc version in use (e.g. tested is debian glibc 2.24-11+deb9u1) but can with minimal amount of work be ported to any libc version on any patch level to our knowledge

Of course you can also use the exploit.py to write your own version of exploit

Additional information

This Vulnerability in ocaml was discovered by me (maximilian.tschirschnitz@gmx.de) and the exploit collaboratly developed with (philipp.hagenlocher@tum.de) For illustration purposes it was packaged as security challenge to demonstrate the impact of the issue (see writeup.pdf)

Description

Insufficient sanitisation in the OCaml compiler versions 4.04.0 and 4.04.1 allows external code to be executed with raised privilege in binaries marked as setuid, by setting the CAMLCPLUGINS, CAMLNATIVECPLUGINS, or CAMLBYTECPLUGINS environment variable.

Bug description

OCaml versions 4.02.3 and earlier have a runtime bug that, on 64-bit platforms, causes sizes arguments to an internal memmove call to be sign-extended from 32 to 64-bits before being passed to the memmove function.

This leads arguments between 2GiB and 4GiB to be interpreted as larger than they are (specifically, a bit below 2^64), causing a buffer overflow.

Arguments between 4GiB and 6GiB are interpreted as 4GiB smaller than they should be, causing a possible information leak.

This commit fixes the bug: https://github.com/ocaml/ocaml/commit/659615c7b100a89eafe6253e7a5b9d84d0e8df74#diff-a97df53e3ebc59bb457191b496c90762 The function camlbitstring is called indirectly from such functions as String.copy. String.copy for instance is supposed to be a "safe" function for which OCaml's memory safety guarantees apply.