[DebianGIS-dev] Bug#474051: libhdf5-serial-dev: libhdf5 appears to write uninitialized memory to file

[Rafael Laboissiere]

* Jason Kraftcheck <kraftche at cae.wisc.edu> [2008-04-02 19:04]:

> Package: libhdf5-serial-dev
> Version: 1.6.5-3
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> 
> valgrind reports writes of unitialized memory in hdf5 library.  This
> could be a serious security issue, depending on what that memory 
> contains.  This can be reproduced by running almost any application
> (that uses the library to write a file) in valigrind. 
> 
> The valgrind error message is:
> 
> ==29786== Memcheck, a memory error detector.
> ==29786== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==29786== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==29786== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==29786== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
> ==29786== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==29786== For more details, rerun with: -v
> ==29786== 
> ==29786== Syscall param write(buf) points to uninitialised byte(s)
> ==29786==    at 0x51119F0: __write_nocancel (in /usr/lib/debug/libc-2.7.so)
> ==29786==    by 0x4E83FCD: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E757DF: H5FD_flush (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6E14A: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6F7B2: H5F_try_close (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6F9BB: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E9B313: H5I_dec_ref (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6D880: H5Fclose (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x400AEE: main (hdf5_bug.c:22)
> ==29786==  Address 0x5add820 is 440 bytes inside a block of size 1,864 alloc'd
> ==29786==    at 0x4C21FAB: malloc (vg_replace_malloc.c:207)
> ==29786==    by 0x4E87873: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E87E05: H5FL_blk_malloc (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E883A3: H5FL_blk_realloc (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E75D9F: H5FD_write (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6C9A1: H5F_block_write (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4EA05EA: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E505B0: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E51826: H5C_flush_cache (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E4C16E: H5AC_flush (in /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6DF8C: (within /usr/lib/libhdf5-1.6.5.so.0.0.0)
> ==29786==    by 0x4E6F7B2: H5F_try_close (in /usr/lib/libhdf5-1.6.5.so.0.0.0)

I cannot reproduce the problem above with libhdf5-serial-1.6.6, version
1.6.6-4 (currently in unstable).  Using the C program that you provided, I
get the following output from valgrind:

==11598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==11598== malloc/free: in use at exit: 1,312 bytes in 2 blocks.
==11598== malloc/free: 1,014 allocs, 1,012 frees, 494,404 bytes allocated.
==11598== For counts of detected errors, rerun with: -v
==11598== searching for pointers to 2 not-freed blocks.
==11598== checked 142,048 bytes.
==11598==
==11598== LEAK SUMMARY:
==11598==    definitely lost: 0 bytes in 0 blocks.
==11598==      possibly lost: 0 bytes in 0 blocks.
==11598==    still reachable: 1,312 bytes in 2 blocks.
==11598==         suppressed: 0 bytes in 0 blocks.

Could you please confirm this?

-- 
Rafael