* Jason Kraftcheck <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
