hdf5
hdf5 copied to clipboard
HDFGroup
heap-buffer-overflow in H5T__bit_find
Describe the bug
==1989==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004b58 at pc 0x000000bdf5f9 bp 0x7fffd47546d0 sp 0x7fffd47546c8 READ of size 1 at 0x602000004b58 thread T0 # 0 0xbdf5f8 in H5T__bit_find hdf5/src/H5Tbit.c:0:20 # 1 0xd7431a in H5T__conv_f_i hdf5/src/H5Tconv.c:9257:29 # 2 0xbd94e2 in H5T_convert_with_ctx hdf5/src/H5T.c:5962:14 # 3 0xbcf284 in H5T_convert hdf5/src/H5T.c:5897:9 # 4 0x7b81ad in H5D__scatgath_read hdf5/src/H5Dscatgath.c:578:17 # 5 0xeb98c7 in H5D__contig_read hdf5/src/H5Dcontig.c:893:13 # 6 0x7aaadf in H5D__read hdf5/src/H5Dio.c:398:17 # 7 0xddb06a in H5VL__native_dataset_read hdf5/src/H5VLnative_dataset.c:373:9 # 8 0xda0d45 in H5VL__dataset_read hdf5/src/H5VLcallback.c:2047:9 # 9 0xda0d45 in H5VL_dataset_read_direct hdf5/src/H5VLcallback.c:2090:9 # 10 0x771ba2 in H5D__read_api_common hdf5/src/H5D.c:1006:9 # 11 0x770d6a in H5Dread hdf5/src/H5D.c:1059:9
0x602000004b58 is located 0 bytes to the right of 8-byte region [0x602000004b50,0x602000004b58) allocated by thread T0 here: # 0 0x5303ee in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3 # 1 0xd739e4 in H5T__conv_f_i hdf5/src/H5Tconv.c:8985:34 # 2 0xbd94e2 in H5T_convert_with_ctx hdf5/src/H5T.c:5962:14 # 3 0xbcf284 in H5T_convert hdf5/src/H5T.c:5897:9 # 4 0x7b81ad in H5D__scatgath_read hdf5/src/H5Dscatgath.c:578:17 # 5 0xeb98c7 in H5D__contig_read hdf5/src/H5Dcontig.c:893:13 # 6 0x7aaadf in H5D__read hdf5/src/H5Dio.c:398:17 # 7 0xddb06a in H5VL__native_dataset_read hdf5/src/H5VLnative_dataset.c:373:9 # 8 0xda0d45 in H5VL__dataset_read hdf5/src/H5VLcallback.c:2047:9 # 9 0xda0d45 in H5VL_dataset_read_direct hdf5/src/H5VLcallback.c:2090:9 # 10 0x771ba2 in H5D__read_api_common hdf5/src/H5D.c:1006:9 # 11 0x770d6a in H5Dread hdf5/src/H5D.c:1059:9
Additional context
Reported for c5c4713a9a0c940a6d20daad1152a3fc80b4fec5.
We monitor oss-fuzz, so there's no need to re-create issues here. Also, these issues are not particularly useful without the poc files.
Right. The issues are reported for libmatio (with restricted access only) and I dot not know if the same issues are also reported for your setup. It's all due to #272.
Right, but they also purposely disclose those privately so that maintainers can patch their code before the public is alerted. Putting oss-fuzz issues in GitHub defeats that purpose. Please don't do it. Our goal is to fix everything outstanding for 1.14.5 and then stay oss-fuzz clean in the future. Thanks!
This still leaves the question how do you know about the hdf5-related issues reported for libmatio? They are reported with restricted access to me and not for libhdf5.
One other point is that I only reported the issues that got recently introduced in the development version. In case of #4293 and #4307 it worked out to be fixed for 1.14.4. I do not know if they would have been addressed early if not reported.
If you care about disclosure you can set up GitHub to enable privatly reported security issues: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability. This would help in my case. Edit: You already did so and I may use it if you prefer.
This is verified as fixed now: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=67905