From ${URL} : Exiv2 crashes on the attached file: $ exiv2 pr crash.riff *** Error in `exiv2': double free or corruption (!prev): 0x09669910 *** Aborted Valgrind says it's a buffer overflow: ==5509== Invalid write of size 4 ==5509== at 0x452BD6C: __GI_mempcpy (mempcpy.S:54) ==5509== by 0x451E307: _IO_file_xsgetn (fileops.c:1388) ==5509== by 0x45200B7: _IO_sgetn (genops.c:495) ==5509== by 0x4513998: fread (iofread.c:42) ==5509== by 0x40AF816: fread (stdio2.h:295) ==5509== by 0x40AF816: Exiv2::FileIo::read(unsigned char*, long) (basicio.cpp:941) ==5509== by 0x415B513: Exiv2::RiffVideo::dateTimeOriginal(long, int) (riffvideo.cpp:695) ==5509== by 0x4162401: Exiv2::RiffVideo::tagDecoder(Exiv2::DataBuf&, unsigned long) (riffvideo.cpp:611) ==5509== by 0x41625C8: Exiv2::RiffVideo::decodeBlock() (riffvideo.cpp:574) ==5509== by 0x41629B0: Exiv2::RiffVideo::readMetadata() (riffvideo.cpp:549) ==5509== by 0x805F61F: Action::Print::printSummary() (actions.cpp:258) ==5509== by 0x8061AFC: Action::Print::run(std::string const&) (actions.cpp:236) ==5509== by 0x804C3D0: main (exiv2.cpp:171) ==5509== Address 0x46b6081 is 97 bytes inside a block of size 100 alloc'd ==5509== at 0x4029DFC: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==5509== by 0x415B4F9: DataBuf (types.hpp:199) ==5509== by 0x415B4F9: Exiv2::RiffVideo::dateTimeOriginal(long, int) (riffvideo.cpp:694) ==5509== by 0x4162401: Exiv2::RiffVideo::tagDecoder(Exiv2::DataBuf&, unsigned long) (riffvideo.cpp:611) ==5509== by 0x41625C8: Exiv2::RiffVideo::decodeBlock() (riffvideo.cpp:574) ==5509== by 0x41629B0: Exiv2::RiffVideo::readMetadata() (riffvideo.cpp:549) ==5509== by 0x805F61F: Action::Print::printSummary() (actions.cpp:258) ==5509== by 0x8061AFC: Action::Print::run(std::string const&) (actions.cpp:236) ==5509== by 0x804C3D0: main (exiv2.cpp:171) @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Is upstream even aware of this?
(In reply to Michael Palimaka (kensington) from comment #1) > Is upstream even aware of this? As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781123#11 , the answer is no
I don't know what we're supposed to do about it then.
I think this is invalid. The latest comments in the debian bug say that this affects only video support, this is disabled by default and upstream recommends disabling it because they know their video code is insecure. The Gentoo ebuild doesn't enable video either and there is no USE flag for it, so I think everything's fine here. (also I tried and can't reproduce the bug)
(In reply to Hanno Boeck from comment #4) > I think this is invalid. > > The latest comments in the debian bug say that this affects only video > support, this is disabled by default and upstream recommends disabling it > because they know their video code is insecure. > > The Gentoo ebuild doesn't enable video either and there is no USE flag for > it, so I think everything's fine here. (also I tried and can't reproduce the > bug) Removing kde from cc. Please add back when there is something to do.
As this become stable? Mike Boyle Gentoo Security Padawan
(In reply to Michael Boyle from comment #6) > As this become stable? EXIV2_ENABLE_VIDEO is off by default and not enabled by our ebuilds either.
@maintainer(s), Per comment4 and comment7, is it okay to close on this bug? Gentoo Security Padawan (jmbailey/mbailey_j)
That's what my comment was implying, yes.