Bug 696096 - Tracking bug for memcpy overlap issues
Summary: Tracking bug for memcpy overlap issues
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
URL:
Whiteboard:
Depends On: 696101 696103 698439 705423
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-13 09:09 UTC by Felipe Contreras
Modified: 2014-03-17 03:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-02 21:56:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Code to check for memcpy overlaps (255 bytes, text/x-csrc)
2011-04-13 09:09 UTC, Felipe Contreras
no flags Details
debug info xulrunner (51.66 KB, text/plain)
2011-04-13 11:30 UTC, Brent R Brian
no flags Details
flash failure on Acer Aspire 5734z-4836 (27.14 KB, text/plain)
2011-04-13 16:57 UTC, Brent R Brian
no flags Details
Code to check for memcpy overlaps (269 bytes, text/x-csrc)
2011-04-20 14:00 UTC, Felipe Contreras
no flags Details
unzip stacktrace (6.60 KB, application/octet-stream)
2011-05-02 18:32 UTC, David Füreder
no flags Details

Description Felipe Contreras 2011-04-13 09:09:35 UTC
Created attachment 491687 [details]
Code to check for memcpy overlaps

Thanks to recent optimizations in glibc where the memcpy happens backwards, it suddenly becomes more important that memcpy is used properly (without overlaps).

For reference, see bug #638477 and:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518

So, we need to check for those system-wide, otherwise there would be silent failures here and there. Right now Flash and squashfs has been identified, but I found others, such as pulsaudio and readahead-collector.

In order to check for these easily I'm attaching a memcpy check that can be ld preloaded:

% gcc -O2 -fPIC -Wall -Werror memcpy_check.c --shared -o /tmp/memcpy_check.so
% echo /tmp/memcpy_check.so > /etc/ld.so.preload

Comment 1 Jakub Jelinek 2011-04-13 09:42:01 UTC
You can use
http://people.redhat.com/wcohen/memstomp/

Comment 2 Felipe Contreras 2011-04-13 09:54:12 UTC
(In reply to comment #1)
> You can use
> http://people.redhat.com/wcohen/memstomp/

Yeah, but you have to know which process you want to check beforehand.

The purpose of this is to check for the *whole* system... Sort of gprof vs perf.

Comment 3 Brent R Brian 2011-04-13 10:32:11 UTC
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a pax tar archive... gnutar
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... -std=gnu99
checking whether gcc -std=gnu99 and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether gcc -std=gnu99 needs -traditional... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... no
checking if gcc -std=gnu99 supports -c -o file.o... yes
checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes
checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for library containing bfd_init... no
configure: error: *** libbfd not found

Comment 4 Brent R Brian 2011-04-13 10:50:27 UTC
Where are the result of the "test" going to show up?

I have several systems, one I KNOW has the buggy flash ...

Comment 5 Felipe Contreras 2011-04-13 11:00:51 UTC
(In reply to comment #4)
> Where are the result of the "test" going to show up?
> 
> I have several systems, one I KNOW has the buggy flash ...

It will show as a crash, so abbrt should catch them. I'm talking of course of the test I mentioned in my description of this bug.

Comment 6 Brent R Brian 2011-04-13 11:29:36 UTC
the memcpy_check seems to be working:

ABRT: won't let me file a bug report on debuginfo-install xulrunner, and xulrunner is crapping out every time it runs (this machine used to run flash without any noticed issues).

Please see attached "text file" with cut/paste of abrt dump.

Comment 7 Brent R Brian 2011-04-13 11:30:13 UTC
Created attachment 491727 [details]
debug info xulrunner

Comment 8 Brent R Brian 2011-04-13 16:57:45 UTC
Created attachment 491837 [details]
flash failure on Acer Aspire 5734z-4836

This attachment is from a dual pentium T4500

Comment 9 Felipe Contreras 2011-04-13 17:31:18 UTC
(In reply to comment #8)
> Created attachment 491837 [details]
> flash failure on Acer Aspire 5734z-4836
> 
> This attachment is from a dual pentium T4500

That one is not in Fedora, that's Adobe:
https://bugs.adobe.com/jira/browse/FP-5739

Comment 10 Brent R Brian 2011-04-13 17:49:22 UTC
Unfortunately, I can not test the "sound bug" when the memcpy_check is blowing the flash player out of the water ... all SUGGESTIONS welcome.

Is there a "glibc" F14 that I can install to check the fix ?

Comment 11 Felipe Contreras 2011-04-13 18:32:30 UTC
(In reply to comment #10)
> Unfortunately, I can not test the "sound bug" when the memcpy_check is blowing
> the flash player out of the water ... all SUGGESTIONS welcome.

You are just introducing noise to this bug, so let me explain it _once_.

Flash has a bug in the way it uses memcpy, period. All memcpy_check is doing is exposing the bug, by crashing each time memcpy is used wrongly. Blowing Flash out of the what is exactly it's purpose, if that's not what you want, don't use it.

If you want your Flash fixed, go to Adobe, this bug is not related to that in any way.

I repeat, do _not_ post any Flash adobe related issues here, that is out of topic.

> Is there a "glibc" F14 that I can install to check the fix ?

Which fix? There is no fix from Adobe.

If you want Flash to work you can modify memcpy_check to remove the check:

---
#include <string.h>

void *memcpy(void *dst, const void *src, size_t n)
{
	return memmove(dst, src, n);
}
---

But again, that has nothing to do with this bug. Please stop.

Comment 12 Felipe Contreras 2011-04-20 14:00:21 UTC
Created attachment 493497 [details]
Code to check for memcpy overlaps

Corrected code to check for overlaps.

The check was failing if src == dst.

Comment 13 David Füreder 2011-05-02 18:32:06 UTC
Created attachment 496332 [details]
unzip stacktrace

Created with gdb.

Comment 14 David Füreder 2011-05-02 18:35:24 UTC
Comment on attachment 496332 [details]
unzip stacktrace

unzip from unzip-6.0-3.fc14.x86_64 crashes when using unzip -t somefile.zip

Comment 15 Felipe Contreras 2011-06-06 14:08:35 UTC
(In reply to comment #14)
> Comment on attachment 496332 [details]
> unzip stacktrace
> 
> unzip from unzip-6.0-3.fc14.x86_64 crashes when using unzip -t somefile.zip

You should file a separate bug report to the 'unzip' component, and mark it as blocking this one.

Comment 16 Felipe Contreras 2011-06-06 14:11:16 UTC
Attachment #491727 [details] and and attachment #491837 [details] should be marked as obsolete, probably attachment #496332 [details] too.

Comment 17 Felipe Contreras 2012-02-02 21:56:25 UTC
Nobody seems to care.


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