Re: Bug#624743: cannot reproduce

[Samuel Thibault]

found 624743 4.6.0-8
thanks

Hello,

hurd-i386 is also hit by the bug.

Andreas Metzler, le Fri 06 May 2011 20:16:49 +0200, a écrit :
> On 2011-05-05 Kees Cook <kees@debian.org> wrote:
> > Hi! Thanks for this report. I can't reproduce this segfault. I tried the
> > builds both amd64 and i386, and both build fine with 4.6.0-6 for me. Do you
> > have any minimal reproducers that might show this more specifically?
> 
> Sadly I cannot reproduce this anymore either. Some of the since
> upgraded build-deps must have changed.

I can reproduce it with gcc-4.6 4.6.0-8, but only by using valgrind: in
debian/minimaltest, prepend valgrind to the line

$2 -C "$top/exim4.conf" -bV

valgrind will then warn:

==29180== Source and destination overlap in memcpy(0x6fad4e8, 0x6fad4e0, 88)
==29180==    at 0x4C25F6A: memcpy (mc_replace_strmem.c:497)
==29180==    by 0x13B5D9: init_lookup_list (string3.h:59)
==29180==    by 0x11FF6E: main (exim.c:3615)

which is the same backtrace reported here. Disassembling
init_lookup_list shows this:

   0x00000000000335cb <+459>:   cltq   
   0x00000000000335cd <+461>:   lea    0x0(,%rax,8),%rdx
   0x00000000000335d5 <+469>:   callq  0x153a8 <memcpy@plt>
   0x00000000000335da <+474>:   mov    %rbx,%rcx
   0x00000000000335dd <+477>:   add    0x2b6fac(%rip),%rcx        # 0x2ea590 
<lookup_list>
   0x00000000000335e4 <+484>:   mov    0x18(%rsp),%rdx

i.e. a memcpy call. l * 0x00000000000335d5 points at

59        return __builtin___memmove_chk (__dest, __src, __len, __bos0 
(__dest));

which is actually a memmove call, not a memcpy call!  The memmove call
comes from the add_lookup_to_list() inline.  By replacing it with
__builtin_memmove() to avoid the _chk version, I don't get any valgrind
issue any more.

It looks like gcc-4.6 is here erroneously optimizing
__builtin___memmove_chk into a memcpy call!

Samuel