Outmaster/hdf5-onion-overflow-poc

HDF5 onion VFD revision-record integer-overflow PoC (illustrative fields)

Proof-of-concept material for a huntr Model Format Vulnerability report against HDFGroup/hdf5 (src/H5FDonion_index.c, H5FD__onion_revision_record_decode()).

evil_revision_record.bin is a 64-byte buffer matching the exact, byte-for-byte field layout of an onion-VFD revision record header, verified directly against the live source (H5FDonion_index.c, function starting at line 586; signature/version constants from H5FDonion_index.h):

• bytes 0-3: signature "ORRS" (H5FD_ONION_REVISION_RECORD_SIGNATURE)
• byte 4: version 1 (H5FD_ONION_REVISION_RECORD_VERSION_CURR)
• bytes 5-7: reserved/skipped (decode starts reading fixed fields at buf+8)
• bytes 8-15: revision_num (uint64) = 0
• bytes 16-23: parent_revision_num (uint64) = 0xFFFFFFFFFFFFFFFF (sentinel)
• bytes 24-39: time_of_creation (16 bytes) = 0
• bytes 40-47: logical_eof (uint64) = 0
• bytes 48-51: page_size (uint32) = 4096 (must be non-zero power of two - this passes the function's own POWER_OF_TWO check)
• bytes 52-59: n_entries (uint64) = 0xFFFFFFFFFFFFFFFF - the attacker-controlled field this report is about
• bytes 60-63: comment_size (uint32) = 0

H5FD__onion_ingest_revision_record() (lines 145, 149-150) allocates H5MM_calloc(n_entries * sizeof(entry)) from this field with no upper-bound check. H5MM_calloc is literally #define H5MM_calloc(Z) calloc(1, Z) - the multiplication n_entries * sizeof(entry) happens in the caller, in 64-bit arithmetic, BEFORE calloc's own internal overflow protection ever sees it. With n_entries = 0xFFFFFFFFFFFFFFFF and H5FD_ONION_ENCODED_SIZE_INDEX_ENTRY = 20 (bytes per entry, H5FDonion_index.h), the true product wraps around 2^64, which can produce an undersized calloc allocation followed by a decode loop that writes n_entries index entries into it - a potential heap buffer overflow, not just a disproportionate-allocation DoS.

Reachable via H5Pset_fapl_onion(), a documented public API (no experimental/unsupported marking) built into the base HDF5 library (CMakeLists.txt, no feature flag needed). The project's own SECURITY.md explicitly lists DoS/crash as "Usually In Scope".

Honest limits (not swept under the rug)

This 64-byte buffer is the isolated, byte-verified revision-record header fragment - it is not a complete onion-format overlay file spliced onto a real HDF5 base file, and no live crash/heap-overflow was reproduced on this host (building libhdf5 with the onion VFD from source, or installing the system package, was not done here - no root access to install system packages, and a from-source build was judged too large an addition for this report). An earlier independent blind-adversarial code review reached the same conclusion from reading the same source and explicitly flagged this exact escalation (integer-overflow -> undersized calloc -> OOB write) as "plausible, but not proven all the way to a live crash" - this report does not claim more certainty than that review established.

Impact: potentially a heap buffer overflow (not just DoS) via a crafted onion-format revision record with an oversized n_entries field, though the escalation from integer-overflow to actual out-of-bounds write has not been runtime-confirmed.