Bug 53854 - memcpy call with overlapping regions
Summary: memcpy call with overlapping regions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: qt   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-19 22:56 UTC by Need Real Name
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 17:44:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-09-19 22:56:48 UTC
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):


How Reproducible:
Very reproducible.

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.

Comment 1 Bernhard Rosenkraenzer 2001-09-27 13:27:39 UTC
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?

Comment 2 Need Real Name 2001-09-30 00:31:47 UTC
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?

Comment 3 Need Real Name 2001-09-30 00:38:58 UTC
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...

Comment 4 Matthias Clasen 2004-05-12 17:21:49 UTC
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.

Comment 5 Ngo Than 2004-05-12 17:44:17 UTC
since RHL8 qt does not use own libpng anymore. It just uses system libpng.

Note You need to log in before you can comment on or make changes to this bug.