This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 696096

Summary: Tracking bug for memcpy overlap issues
Product: [Fedora] Fedora Reporter: Felipe Contreras <felipe.contreras>
Component: distributionAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Bill Nottingham <notting>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: mathieu-acct, milan.kerslager, mishu, rdieter, robatino, rvokal, thierry.vignaud, tmraz, tom
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-02 16:56:25 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 696101, 696103, 698439, 705423    
Bug Blocks:    
Attachments:
Description Flags
Code to check for memcpy overlaps
none
debug info xulrunner
none
flash failure on Acer Aspire 5734z-4836
none
Code to check for memcpy overlaps
none
unzip stacktrace none

Description Felipe Contreras 2011-04-13 05:09:35 EDT
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 05:42:01 EDT
You can use
http://people.redhat.com/wcohen/memstomp/
Comment 2 Felipe Contreras 2011-04-13 05:54:12 EDT
(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 06:32:11 EDT
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 06:50:27 EDT
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 07:00:51 EDT
(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 07:29:36 EDT
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 07:30:13 EDT
Created attachment 491727 [details]
debug info xulrunner
Comment 8 Brent R Brian 2011-04-13 12:57:45 EDT
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 13:31:18 EDT
(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 13:49:22 EDT
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 14:32:30 EDT
(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 10:00:21 EDT
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 14:32:06 EDT
Created attachment 496332 [details]
unzip stacktrace

Created with gdb.
Comment 14 David Füreder 2011-05-02 14:35:24 EDT
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 10:08:35 EDT
(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 10:11:16 EDT
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 16:56:25 EST
Nobody seems to care.