Skip to content

Fix memory leak of continuation messages on object header deserialize failure - #6620

Open
tbeu wants to merge 1 commit into
HDFGroup:developfrom
tbeu:fix/issue-6386-obj-header-cont-msg-leak
Open

tbeu wants to merge 1 commit into
HDFGroup:developfrom
tbeu:fix/issue-6386-obj-header-cont-msg-leak

Conversation

@tbeu

@tbeu tbeu commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes a memory leak reported by OSS-Fuzz via the matio project's fuzzer (closes #6386).

\
Direct leak of 56 byte(s) ... allocated from:
# 3 H5O__add_cont_msg hdf5/src/H5Ocache.c
# 4 H5O__chunk_deserialize hdf5/src/H5Ocache.c
# 5 H5O__cache_deserialize hdf5/src/H5Ocache.c
...
# 17 H5Rdereference2
\\

Root cause

\H5O__cache_deserialize()\ allocates the continuation-message array
(\cont_msg_info->msgs, via \H5O__add_cont_msg()\ -> \H5FL_SEQ_REALLOC) while parsing the first object-header chunk. The caller \H5O_protect()\ only frees that array on the success path (H5Ocache.c:1075) or on failure *when \oh != NULL* (rule at H5Ocache.c:1142). When the deserialize fails after continuation messages were accumulated (e.g. the v1 \�1_pfx_nmesgs < oh->nmesgs\ check at H5Ocache.c:305), \H5O__cache_deserialize()\ returns \NULL\ and \H5O_protect()'s \oh\ stays \NULL, so its cleanup is skipped and the 56-byte array leaks.

Fix

Free \cont_msg_info->msgs\ in \H5O__cache_deserialize()'s own \done\ block on error. \H5FL_seq_free()\ returns \NULL, so this is safe against a double-free with the caller's guarded free (which becomes a no-op once the array is \NULL).

Verification

Compiles cleanly in both Release and Debug \hdf5-static\ builds and links into a Debug repro exercising matio's exact API paths (\H5Oget_info_by_name3\ + \H5Rdereference2\ on reference datasets). The leak is specific to v1 object headers (the post-continuation \�1_pfx_nmesgs < oh->nmesgs\ check), which is why the leak manifests in the 2.2.0 OSS-Fuzz environment described in the issue.

Checklist

  • PR is based on the develop branch
  • Only \src/H5Ocache.c\ is changed

… failure (HDFFV-6386)

When H5O__cache_deserialize() fails after continuation messages have
already been accumulated into cont_msg_info->msgs (e.g. the v1
'v1_pfx_nmesgs < oh->nmesgs' check at H5Ocache.c:305), it returned
NULL while leaving the caller's H5O_protect() with oh == NULL.  The
existing cleanup in H5O_protect() only frees cont_msg_info->msgs when
oh != NULL, so the continuation-message array was leaked.

Free cont_msg_info->msgs in H5O__cache_deserialize()'s own done block
on error.  H5FL_seq_free() returns NULL, so this is safe against a
double-free with the caller's guarded free.

Found by OSS-Fuzz via the matio project's fuzzer (see
HDFGroup#6386).
@github-actions

Copy link
Copy Markdown
Contributor

Review Checklist

This PR touches the following areas. Each needs a sign-off
from its listed owners before merging.

@hyoklee hyoklee added the Component - C Library Core C library issues (usually in the src directory) label Aug 25, 2026
@hyoklee hyoklee moved this from To be triaged to Planning in HDF5 - TRIAGE & TRACK Aug 25, 2026
@hyoklee hyoklee added this to the HDF5 2.2.1 milestone Aug 25, 2026
@nbagha1 nbagha1 modified the milestones: HDF5 2.2.1, HDF5 2.3.0 Sep 11, 2026
@github-actions github-actions Bot added the stale label Sep 18, 2026
@github-actions

Copy link
Copy Markdown
Contributor

This pull request has had no activity for 30 days and has been marked stale. Push a commit or comment to keep it open, or it will be flagged for maintainer review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Component - C Library Core C library issues (usually in the src directory) stale

Projects

Status: Planning

Development

Successfully merging this pull request may close these issues.

Memory leak in H5O__add_cont_msg when opening corrupted object via H5Rdereference

4 participants