Proof-of-concept for a heap out-of-bounds READ (denial of service) in hsnyder/safetensors.h, function safetensors_parse_positive_int() at safetensors.h:361. Class: CWE-125 out-of-bounds read (reliable DoS). Format: SafeTensors (.safetensors).

safetensors_parse_positive_int() skips leading spaces/tabs with while(*str == ' ' || *str == '\t') str++; with NO str < limit bound. Every sibling parse loop in the file IS bounded by str < limit; this one is not (its own doc comment even claims "Won't read past 'limit'"). When an integer-list value in the header (shape or data_offsets) ends with whitespace running to the end of the buffer, the loop reads past the caller's allocation.

poc.safetensors.base64 is a 26-byte PoC (base64). Decode with base64 -d poc.safetensors.base64 > poc.safetensors. It has an honest 8-byte length prefix (header_len=18) plus the header {"t":{"shape":[ } with three trailing spaces. "Valid" here means the length prefix and buffer size are correct; the JSON body is intentionally truncated inside an integer list.

AddressSanitizer: heap-buffer-overflow READ of size 1 ... safetensors_parse_positive_int safetensors.h:361 ... 0 bytes after 26-byte region (call chain eat_intlist -> eat_kv_pair -> file_init).

CWE-125 OOB READ = reliable DoS. This is NOT an information leak: the over-read bytes are only compared to space/tab and never stored, and the following digit loop is bounded, so the returned integer uses only in-bounds digits (verified via an A/B test). It fires on a file with an honest length prefix, so it is a distinct root from any header-length over-read: a one-line str < limit fix at line 361 closes only this bug, while a header-length-validation fix leaves it fully live (confirmed by a measured single-fix differential). Caveats: low-adoption library (~8 stars), independent C implementation (not the official safetensors), last commit 2025-06-08. Fix: while(str < limit && (*str == ' ' || *str == '\t')) str++; ]}}