heap-buffer-overflow in H5T__bit_find

[thbeu]

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 c5c4713.

[derobins]

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.

[tbeu]

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.

[tbeu]

Here comes the testfile.zip

[derobins]

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!

[tbeu]

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.

[tbeu]

This is verified as fixed now: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=67905