[DebianGIS-dev] Bug#474051: libhdf5-serial-dev: libhdf5 appears to write uninitialized memory to file
Rafael Laboissiere wrote: > > 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? > I cannot reproduce them problem with 1.6.6 (not debian package.) I have seen similar errors with 1.6.6 (and 1.8.0) with real applications. If I find a simple way to reproduce the problem, I will submit a new bug report against 1.6.6. ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#474051: libhdf5-serial-dev: libhdf5 appears to write uninitialized memory to file
* 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 ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#474051: libhdf5-serial-dev: libhdf5 appears to write uninitialized memory to file
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)
As I said above, I think almost any practical use of the library will
cause this. But just in case the error is due to a gross misunderstanding
of how I should use this library, here's the test code I used to generate
the above output:
#include
int main()
{
hid_t file, table, space, mem_space;
hsize_t ones[2] = { 1, 1 };
int an_int = 5;
H5open();
remove( "test.hdf5" );
file = H5Fcreate( "test.hdf5", H5F_ACC_EXCL, H5P_DEFAULT, H5P_DEFAULT );
space = H5Screate_simple( 2, ones, NULL );
table = H5Dcreate( file, "data", H5T_NATIVE_INT, space, H5P_DEFAULT );
mem_space = H5Screate_simple( 1, ones, NULL );
H5Dwrite( table, H5T_NATIVE_INT, mem_space, space, H5P_DEFAULT, &an_int );
H5Sclose( mem_space );
H5Dclose( table );
H5Sclose( space );
H5Fclose( file );
H5close();
return 0;
}
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libhdf5-serial-dev depends on:
ii libc6-dev 2.7-6 GNU C Library: Development Librari
ii libhdf5-serial-1.6.5-0 1.6.5-3 Hierarchical Data Format 5 (HDF5)
ii libjpeg62-dev 6b-13 Development files for the IJG JPEG
ii zlib1g-dev 1:1.2.3.3.dfsg-11 compression library - development
libhdf5-serial-dev recommends no packages.
-- no debconf information
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
