CVE-2026-34353: 
NixOS vulnerability analysis and mitigation

CVE-2026-34353 is an integer overflow vulnerability in OCaml's Bigarray.reshape function that allows reading of arbitrary memory when untrusted data is processed. It affects OCaml through version 4.14.3, as well as Microsoft's OCaml packages (cbl2_ocaml_4.13.1-2, cbl2_ocaml_4.13.1-3, azl3_ocaml_5.1.1-1, and azl3_ocaml_5.1.1-2). The vulnerability was reported on March 18, 2026, publicly disclosed on March 27, 2026, and a patch was made available by March 31, 2026. It carries a CVSS v3.1 base score of 5.1 (Medium) per NVD, or 5.9 (Medium) per ENISA, reflecting a local, high-complexity attack with high confidentiality impact (GitHub Issue, MSRC).

The root cause is an integer overflow (CWE-190) in the caml_ba_reshape function within bigarray.c. When Bigarray.reshape is called with attacker-controlled dimension arrays containing very large values (e.g., [|8; 2305843009213693952|]), the product of dimensions overflows, causing caml_ba_num_elts to return 0 while the underlying data pointer remains unchanged and unallocated. This allows subsequent array index operations to read from uninitialized or arbitrary memory without triggering bounds-check exceptions. The fix, merged as PR #14691, adds explicit overflow checking in caml_ba_reshape before passing dimensions to caml_ba_alloc; the 5.x branch was already protected by a side-effect of PR #11022, but the 4.14 branch required a dedicated backport (GitHub Issue, GitHub PR).

Successful exploitation allows a local attacker to read sensitive data from arbitrary or uninitialized memory locations, resulting in a high confidentiality impact with no integrity or availability impact. Applications that process untrusted data through OCaml's Bigarray module — such as scientific computing libraries, data processing pipelines, or sandboxed runtimes — are at risk of leaking sensitive in-memory information. The ENISA assessment notes potential for data exposure across system boundaries, though lateral movement is not a direct consequence of this read-only memory disclosure (MSRC, GitHub Issue).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of reporting. The EPSS score is approximately 0.013%, reflecting a very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access and high complexity, limiting the practical attack surface (Feedly, MSRC).

1. Identify target: Locate an application or service running OCaml ≤ 4.14.3 that accepts untrusted input and passes it to Bigarray.reshape (e.g., a data processing service or scientific computing application).
2. Craft overflow dimensions: Prepare a dimension array whose product overflows a 64-bit integer, such as [|8; 2305843009213693952|] (8 × 2^57 = 2^60, which overflows when multiplied by the element size).
3. Trigger reshape: Supply the crafted dimensions to Bigarray.reshape on a zero-element array, causing caml_ba_num_elts to return 0 while the data pointer remains at its original (unallocated or previously freed) location.
4. Read arbitrary memory: Perform array index operations (e.g., Array2.get x 5 5) on the reshaped array; bounds checks pass incorrectly, allowing reads from arbitrary memory addresses and leaking sensitive data (GitHub Issue, GitHub PR).

Upgrade OCaml to a version newer than 4.14.3, which includes the fix from PR #14691 adding overflow checking in caml_ba_reshape. Microsoft users should apply the security updates available from MSRC for the affected packages (cbl2_ocaml_4.13.1-2/3 and azl3_ocaml_5.1.1-1/2). As a workaround where patching is not immediately possible, avoid passing untrusted data directly to Bigarray.reshape and validate dimension arrays for overflow before use (MSRC, GitHub PR).

The OCaml security team reviewed the issue and determined the fix present in OCaml 5.x (via PR #11022) should be backported to the 4.14 branch. Contributor stedolan provided a detailed analysis clarifying that the correct fix is to add overflow checking in caml_ba_reshape itself rather than relying on caml_ba_alloc, leading to the closure of PR #14674 in favor of the more targeted PR #14691. The vulnerability received routine coverage from vulnerability tracking services (NVD, ENISA, INCIBE) but no significant broader media attention, consistent with its moderate severity and limited exploitability (GitHub PR, GitHub Issue).