sashashura
commented
11 months ago I do not get the fix, actually.
Inside of H5A__read it calls H5MM_memcpy and tries to copy 16 bytes to fieldnames_vl which is allocated with calloc(0, 16). The calloc documentation doesn't say what is the return value if the first argument (number of objects) is zero, but says: If size is zero, the behavior is implementation defined (null pointer may be returned, or some non-null pointer may be returned that may not be used to access storage). All in all, when calloc is asked to allocate zero memory it doesn't fail with null, but returns a pointer which can be used for realloc or free, but which is illegal to dereference.
The first argument for calloc *nfields is zero, because H5Sget_simple_extent_dims didn't fail (err >= 0), but also didn't set a value to *nfields. It doesn't look as a bug in HDF5, because it is documented in H5S_get_simple_extent_dims (called internally) that This function may not be meaningful for all types of dataspaces. Return: Success: Number of dimensions. Zero implies scalar. It simply returns in scalar case and doesn't touch dims.
You know better if this is invalid situation and should be rejected at all, but it looks to me, that it is ok to set the number of objects to 1 in case of scalar.
tbeu
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58262
The root cause is that
H5Sget_simple_extent_dimsdoesn't fail and doesn't initialize*nfieldsfor scalar types, so it is left zero. Behavior ofcalloccall with zero size is implementation dependent, but in this case it returns a non null memory which is valid to use only withfree.