Initial implementation of selection I/O with type conversion. Allows
Parallel collective I/O with type conversion, as long as selection I/O
is enabled.
Malformed object header continuation messages can result in a too-small
buffer being passed to the decode function, which could lead to reading
past the end of the buffer. Additionally, errors in processing these
malformed messages can lead to allocated memory not being cleaned up.
This fix adds bounds checking and cleanup code to the object header
continuation message processing.
Fixes#2604
* Fixed GH-2603, heap-buffer-overflow in H5O__linfo_decode
Verified with valgrind -v --tool=memcheck --leak-check=full h5dump POV-GH-2603
The several invalid reads shown originally are now gone.
* Fix for github issue #2599:
As indicated in the description, memory leak is detected when running "./h5dump pov".
The problem is: when calling H5O__add_cont_msg() from H5O__chunk_deserialize(),
memory is allocated for cont_msg_info->msgs. Eventually, when the library tries to load
the continuation message via H5AC_protect() in H5O_protect(), error is
encountered due to illegal info in the continuation message.
Due to the error, H5O_protect() exits but the memory allocated for cont_msg_info->msgs is not freed.
When we figure out how to handle fuzzed files that we didn't generate,
a test needs to be added to run h5dump with the provided "pov" file.
* Add message to release notes for the fix to github issue #2599.
* Remove duplicate code
Signed-off-by: Egbert Eich <eich@suse.com>
* Add test case for CVE-2021-37501
Bogus sizes in this test case causes the on-disk data size
calculation in H5O__attr_decode() to overflow so that the
calculated size becomes 0. This causes the read to overflow
and h5dump to segfault.
This test case was crafted, the test file was not directly
generated by HDF5.
Test case from:
https://github.com/ST4RF4LL/Something_Found/blob/main/HDF5_v1.13.0_h5dump_heap_overflow.md
* Add fetchcontent for compression libs and fix cmake config
* MSDOS is a reserved define name
* Add release note and update install doc for FetchContent
* Add CI test for FetchContent
* Use LINK_COMP_LIBS instead of STATIC_LIBRARY for depends
* Use general link
* CMake generated pkg-config file is incorrect #2259
* Fix fortran pc template
* hdf5.pc is incorrect for debug builds #1546
* Correct pkg name and lib name
* Fix typo
* Fix missing space
* H5F_LIBVER_LATEST changes for move to 1.15
* Add new default api check
* Format fixes
* Fix default configure
* fix lib version tests
* Fix another version variable
* Add 1.14 doc link
* Fix for HDFFV-11052: h5debug fails on a corrupted file (h5_nrefs_POC) producing a core dump.
When h5debug closes the corrupted file, the library calls H5F__dest() which performs all the
closing operations for the file "f" (H5F_t *) but just keeping note of errors in "ret_value"
all the way till the end of the routine. The user-provided corrupted file has an illegal
file size causing failure when reading the image during the closing process.
At the end of this routine it sets f->shared to NULL and then frees "f".
This is done whether there is error or not in "ret_value".
Due to the failure in reading the file earlier, the routine then returns error.
The error return from H5F__dest() causes the file object "f" not being removed from the
ID node table. When the library finally exits, it will try to close the
file objects in the table. This causes assert failure when H5F_ID_EXISTS(f) or H5F_NREFS(f).
Fix:
a) H5F_dest(): free the f only when there is no error in "ret_value" at the end of the routine.
b) H5VL__native_file_close(): if f->shared is NULL, free "f"; otherwise, perform closing on "f" as before.
c) h5debug.c main(): track error return from H5Fclose().
* Committing clang-format changes
* Add test and release note info for fix to HDFFV-11052 which is merged via PR#2291.
* Committing clang-format changes
* Add the test file to Cmake.
Co-authored-by: vchoi <vchoi@jelly.ad.hdfgroup.org>
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Compound datatypes may not have members of size 0
A member size of 0 may lead to an FPE later on as reported in
CVE-2021-46244. To avoid this, check for this as soon as the
member is decoded.
This should probably be done in H5O_dtype_decode_helper() already,
however it is not clear whether all sizes are expected to be != 0.
This fixes CVE-2021-46244 / Bug #2242.
Signed-off-by: Egbert Eich <eich@suse.com>
* Rework error recovery code in H5O__dtype_decode_helper() and
H5O__dtype_decode().
* Format changes for src/H5Odtype.c.
Signed-off-by: Egbert Eich <eich@suse.com>
Co-authored-by: Neil Fortner <nfortne2@hdfgroup.org>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
* When evicting driver info block, NULL the corresponding entry
Since H5C_expunge_entry() called (from H5AC_expunge_entry()) sets the flag
H5C__FLUSH_INVALIDATE_FLAG, the driver info block will be freed. NULLing the
pointer in f->shared->drvinfo will prevent use-after-free when it is used in other
functions (like H5F__dest()) - as other places will check whether the pointer is
initialized before using its value.
This fixes CVE-2021-46242 / Bug #2254
Signed-off-by: Egbert Eich <eich@suse.com>
* When evicting the superblock, NULL the corresponding entry
The call to H5AC_expunge_entry() will free the corresonding structure,
to avoid a use-after-free, the corrsponding pointer entry will be NULLed.
Signed-off-by: Egbert Eich <eich@suse.com>
Signed-off-by: Egbert Eich <eich@suse.com>
For Data Layout Messages version 1 & 2 the specification state
that the value stored in the data field is 1 greater than the
number of dimensions in the dataspace. For version 3 this is
not explicitly stated but the implementation suggests it to be
the case.
Thus the set value needs to be at least 2. For dimensionality
< 2 an out-of-bounds access occurs as in CVE-2021-45833.
This fixes CVE-2021-45833 / Bug #2240.
Signed-off-by: Egbert Eich <eich@suse.com>
Signed-off-by: Egbert Eich <eich@suse.com>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
The size of the enumeration values is determined by the size of the parent.
Functions accessing the enumeration values use the size of the enumeration
to determine the size of each element and how much data to copy. Thus the
size of the enumeration and its parent need to match.
Check here to avoid unpleasant surprises later.
This fixes CVE-2018-14031 / Bug #2236.
Signed-off-by: Egbert Eich <eich@suse.com>
According to the specification, the information block for external links
contains 1 byte of version/flag information and two 0 terminated strings
for the object linked to and the full path.
Although not very useful, the minimum string length for each (with
terminating 0) would be one byte.
Checking this will help to avoid SEGVs triggered by bogus files.
This fixes CVE-2018-16438 / Bug #2233.
Signed-off-by: Egbert Eich <eich@suse.com>
Initially, the accumulated metadata location is initialized to HADDR_UNDEF
- the highest available address. Bogus input files may provide a location
or size matching this value. Comparing this address against such bogus
values may provide false positives. This make sure, the value has been
initilized or fail the comparison early and let other parts of the
code deal with the bogus address/size.
Note: To avoid unnecessary checks, we have assumed that if the 'dirty'
member in the same structure is true the location is valid.
This fixes CVE-2018-13867 / Bug #2230.
Signed-off-by: Egbert Eich <eich@suse.com>
When decoding a file space info message in H5O__fsinfo_decode() make
sure each element to be decoded is still within the message. Malformed
hdf5 files may have trunkated content which does not match the
expected size. Checking this will prevent attempting to decode
unrelated data and heap overflows. So far, only free space manager
address data was checked before decoding.
This fixes CVE-2021-45830 / Bug #2228.
Signed-off-by: Egbert Eich <eich@suse.com>
Additions
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
