Red Hat Bugzilla – Bug 53854
memcpy call with overlapping regions
Last modified: 2007-04-18 12:37:15 EDT
Description of Problem:
We wrote a memcpy replacement in our code base in order to catch
calls to memcpy with overlapping regions and surprisingly, instead
of catching problems in our own code base, we found out that libpng
makes this kind of calls. Here is the stack trace:
Stack trace (5085):
[New Thread 1024 (LWP 5085)]
0x42294519 in __wait4 () from /lib/i686/libc.so.6
#0 0x42294519 in __wait4 () from /lib/i686/libc.so.6
#1 0x423049e4 in __DTOR_END__ () from /lib/i686/libc.so.6
#2 0x42111509 in wait (stat_loc=0xbfffb574) at wrapsyscall.c:167
#3 0x83f149c in doStackTrace () at eval.c:41
#4 0x83f14ee in Arch_LogStackTrace () at eval.c:41
#5 0x83f2802 in memcpy () at eval.c:41
#6 0x4234db73 in png_set_iCCP () from /usr/lib/libpng.so.2
#7 0x42350819 in png_handle_iCCP () from /usr/lib/libpng.so.2
#8 0x42357675 in png_read_info () from /usr/lib/libpng.so.2
#9 0x4141988b in read_png_image () at eval.c:41
#10 0x413cd7d6 in QImageIO::read () at eval.c:41
The call is coming from Qt which is the GUI library we use.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Unfortunately, we cannot provide a test case, but I am hoping that
upon inspection of the png_set_iCCP() function, it may be easy
to deduce why this is happening.
Why are you using libpng-1.0.5-3 on a 7.1 system? 7.1 came with 1.0.9-1, even
7.0 had 1.0.8-1. 1.0.5-3 was in 6.2; did you select the wrong distribution
In any case: The only call to memcpy in png_set_iCCP in recent libpng versions
png_set_iCCP(png_structp png_ptr, png_infop info_ptr,
png_charp name, int compression_type,
png_charp profile, png_uint_32 proflen)
new_iccp_profile = (png_charp)png_malloc(png_ptr, proflen);
png_memcpy(new_iccp_profile, profile, (png_size_t)proflen);
So it is memcpy()'ing a passed parameter to a newly allocated structure. This
looks like the calling application is doing something along the lines of
/* Put something in there */
png_set_iCCP([...], foo, [...]);
read_png_image() in your eval.c might be at fault; QImageIO::read() is another
possibility (and AFAIK QImageIO does require libpng 1.0.8 or higher).
Does this still happen if you update your libpng and possibly Qt?
I am sorry, you are right. The version is 1.0.9-1. I did an rpm -qi
on my 6.2 machine rather than the 7.1. read_png_image is in Qt
so maybe it's Qt that's making the buggy call?
BTW, we are using Qt 2.3. I checked out the 2.3.1 release notes
and they mention some fixes in QImageIO related to saving of
png files. Nothing about loading. Hmm...
Beros analysis seems to be correct. The only way that the memcpy call
in png_set_iCCP() can be overlapping is a bug in the caller, that
would be in Qt.
since RHL8 qt does not use own libpng anymore. It just uses system libpng.