Skip to content

Create memory safe version of H5Dread_chunk() #5224

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fortnern opened this issue Jan 10, 2025 · 0 comments · May be fixed by #5506
Open

Create memory safe version of H5Dread_chunk() #5224

fortnern opened this issue Jan 10, 2025 · 0 comments · May be fixed by #5506
Assignees
Labels
Component - C Library Core C library issues (usually in the src directory) HDFG-internal Internally coded for use by the HDF Group Priority - 0. Blocker This MUST be merged for the release to happen
Milestone

Comments

@fortnern
Copy link
Member

H5Dread_chunk() currently has the signature: herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const hsize_t *offset, uint32_t *filters, void *buf);

This is potentially not memory safe because hte caller does not specify the size of buf. This is especialy problematic because the fitler can potentially increase the size of the chunk, meaning the only way for a caller to definitely know how big buf needs to be is to call H5Dget_chunk_info() first. We should add a size parameter to H5Dread_chunk(), which the caller initializes with the size of buf, and on exit contains the size of the filtered chunk (the needed size of buf). If the buffer is not big enough to read the entire chunk, the contents of buf are unchanged. This would allow the caller to pass a buffer they think is big enough without creating memory (and potentially security) errors if they're wrong and without needed to call H5Dget_Chunk_info() every time, which adds overhead and thereby partially defeats the purpose of the direct chunk I/O interface.

@fortnern fortnern added this to the 2.0.0 milestone Jan 10, 2025
@bmribler bmribler added Priority - 1. High These are important issues that should be resolved in the next release Component - C Library Core C library issues (usually in the src directory) Type - Improvement labels Jan 12, 2025
@mattjala mattjala added Priority - 0. Blocker This MUST be merged for the release to happen and removed Priority - 1. High These are important issues that should be resolved in the next release labels Jan 14, 2025
@nbagha1 nbagha1 added the HDFG-internal Internally coded for use by the HDF Group label Apr 17, 2025
@fortnern fortnern marked this as a duplicate of #5338 May 2, 2025
@fortnern fortnern linked a pull request May 2, 2025 that will close this issue
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) HDFG-internal Internally coded for use by the HDF Group Priority - 0. Blocker This MUST be merged for the release to happen
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants