__memcpy_sse2_unaligned on non-8-byte aligned pointer

Ondřej Bílka neleai@seznam.cz
Thu Jul 9 07:38:00 GMT 2015


On Mon, Jul 06, 2015 at 02:22:32PM +0200, Stephan Bergmann wrote:
> <https://bugzilla.redhat.com/attachment.cgi?id=1048694> is a SIGSEGV
> backtrace where apparently glibc's __memcpy_sse2_unaligned
> (sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S) is trying to
> write to an address that is not 8-byte aligned,
> 
> >Dump of assembler code for function __memcpy_sse2_unaligned:
> >   0x00007fcf46f35b90 <+0>:	mov    %rsi,%rax
> >   0x00007fcf46f35b93 <+3>:	lea    (%rdx,%rdx,1),%rcx
> >   0x00007fcf46f35b97 <+7>:	sub    %rdi,%rax
> >   0x00007fcf46f35b9a <+10>:	sub    %rdx,%rax
> >   0x00007fcf46f35b9d <+13>:	cmp    %rcx,%rax
> >   0x00007fcf46f35ba0 <+16>:	jb     0x7fcf46f35cad <__memcpy_sse2_unaligned+285>
> >   0x00007fcf46f35ba6 <+22>:	cmp    $0x10,%rdx
> >   0x00007fcf46f35baa <+26>:	jbe    0x7fcf46f35d3b <__memcpy_sse2_unaligned+427>
> >   0x00007fcf46f35bb0 <+32>:	movdqu (%rsi),%xmm8
> >   0x00007fcf46f35bb5 <+37>:	cmp    $0x20,%rdx
> >=> 0x00007fcf46f35bb9 <+41>:	movdqu %xmm8,(%rdi)
> [...]
> 
> where rdi is 0x7ffc3830b63c (while rsi is 8-byte aligned at 0x7fcf4a314a08).
> 
> The code leading up to that memcpy call looks rather unsuspecting,
> and it's unclear to me from the crash report data why it caused a
> SIGSEGV.
> 
> However, the Intel documentation for MOVDQU states:  "If alignment
> checking is enabled (CR0.AM = 1, RFLAGS.AC = 1, and CPL = 3), an
> alignment-check exception (#AC) may or may not be generated
> (depending on processor implementation) when the operand is not
> aligned on an 8-byte boundary."
> 
> Could it be plausible that (a) those alignment checking conditions
> are met for a Linux user space process, (b) that alignment-check
> exception would translate into a SIGSEGV (instead of a SIGBUS, say),
> and (c) that there actually are processor implementations that would
> check for non-8-byte alignment?
> 
> It doesn't sound too likely that that would be true, as it would
> mean that arbitrary calls to memcpy (which unconditionally calls
> __memcpy_sse2_unaligned without checking for pointer alignment,
> AFAIU) could fail, but I thought I'd ask here anyway.

Could you check with valgrind first? This is probably just a invalid src
pointer. Basically all string functions use these loads
so alignment checking so it would be bigger problem.



More information about the Libc-help mailing list