Red Hat Bugzilla – Bug 81644
/usr/bin/strip generates garbage from valid ELF executables
Last modified: 2007-04-18 12:49:42 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Description of problem: After applying /usr/bin/strip, executable ELF files that the kernel used to run, will not run anymore. In some cases I see "Illegal instruction", in other cases I see "bash: <a.elf>: cannot execute binary file". One broad case that fails is any ELF executable with e_shoff, e_shentsize, e_shnum, and e_shstrndx all zero. Such a file has an empty "linking view". This is no problem for executing, because execve() uses only the "execution view" [e_phnum, e_phoff, e_phentsize, e_entry], and totally ignores the "linking view". However, if the "linking view" is empty, then the output of 'strip' is just 92 bytes of headers, with no PT_LOAD at all; the file has been totally eviscerated. Trying to run it gets "cannot execute binary file". Instead, 'strip' should detect an empty "linking view", give a warning message, and leave the file alone. Another case that fails is an ELF executable with a second PT_LOAD having 0==.p_memsz, and that is not placed "next" after the first PT_LOAD. Such a PT_LOAD is useful for setting the value of brk(0). 'strip' changes p_vaddr to 0, and p_offset to "next", and also sets p_align to 4, even though the original value was 0x1000. Typically this destroys the relationship (0xfff & p_offset) == (0xfff & p_vaddr) which is required by execve(). Trying to run the result gets "Illegal instruction". 'strip' must preserve PT_LOAD.p_align and everything that it implies in conjunction with p_offset, p_vaddr, p_paddr. Version-Release number of selected component (if applicable): binutils-2.13.90.0.2-2 How reproducible: Always Steps to Reproduce: Using the date.upx.no_shdr and date.upx.shdr ELF executables that are attached to this bugreport: 1../a.elf # normal execution 2./usr/bin/strip ./a.elf # apply 'strip' 3../a.elf # try to execute the result of stripping Actual Results: $ ./date.upx.shdr.strip Illegal instruction $ ./date.upx.no_shdr.strip bash: ./date.upx.no_shdr.strip: cannot execute binary file Expected Results: $ ./date.upx.shdr Sat Jan 11 17:09:06 PST 2003 $ ./date.upx.no_shdr Sat Jan 11 17:09:09 PST 2003 Additional info:
Created attachment 89309 [details] ELF executable with empty "linking view" /bin/date compressed by UPX (http://upx.sourceforge.net)
Created attachment 89310 [details] result of stripping date.upx.no_shdr 92-bytes of headers, and nothing else; 'strip' gutted the file
Created attachment 89311 [details] ELF executable with non-empty, compatible, linking view Output from a test version of UPX that supplies a linking view for compressed output executables.
Created attachment 89312 [details] result of stripping date.upx.shdr The second PT_LOAD has been scrambled: p_align changed from 0x1000 to 4; p_offset changed to inhibit mmap().
Why would 'strip' be applied to output from UPX? rpmbuild does it by default when building a binary package .rpm, and it's not obvious how to turn it off.
*** Bug 76780 has been marked as a duplicate of this bug. ***
binutils-2.15.91.0.2-8 issues warnings: strip date.upx.no_shdr BFD: date.upx.no_shdr: warning: Empty loadable segment detected, is this intentional ? BFD: date.upx.no_shdr: warning: Empty loadable segment detected, is this intentional ? strip: there are no sections to be copied! but doesn't change the binary.