[Bug libc/20596] New: sprintf segmentation fault due to misaligned movaps on x86_64

["andrew.thomas at cogent dot ca" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20596

            Bug ID: 20596
           Summary: sprintf segmentation fault due to misaligned movaps on
                    x86_64
           Product: glibc
           Version: 2.23
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: andrew.thomas at cogent dot ca
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

sprintf and snprintf fail with a segmentation fault due to a movaps instruction
that is not 16-byte aligned.  I run into this with a call like:
   double value = 2.5;
   sprintf (buf, "%.20g", value);

The problem is that sprintf enters with the stack aligned to an arbitrary
boundary and then executes movaps on 16-byte offsets from %rsp.  On my 64-bit
system the stack alignment is 8 bytes.  Depending on the calling sequence
leading up to the sprintf call, sprintf may or may not crash.

The problem gets worse in that sprintf subtracts 0xd8 bytes from %rsp on entry,
so even if the stack is aligned to 16 bytes on function entry, it will be
misaligned by the time it calls movaps.  It's not helpful to compile
application code with -mstackrealign.

Below is the disassembly for sprintf.  The marker is on the point of the
segmentation fault.  In this case sprintf entered with %rsp aligned to 16
bytes, and it subtraced 0xd8 bytes, causing a fatal misalignment.

For what it's worth, this is the up-to-date glibc 2.23 for Ubuntu 16.04 Server
LTS.

(gdb) disass
Dump of assembler code for function __sprintf:
   0x00007ffff71828f0 <+0>:     sub    $0xd8,%rsp
   0x00007ffff71828f7 <+7>:     test   %al,%al
   0x00007ffff71828f9 <+9>:     mov    %rdx,0x30(%rsp)
   0x00007ffff71828fe <+14>:    mov    %rcx,0x38(%rsp)
   0x00007ffff7182903 <+19>:    mov    %r8,0x40(%rsp)
   0x00007ffff7182908 <+24>:    mov    %r9,0x48(%rsp)
   0x00007ffff718290d <+29>:    je     0x7ffff7182946 <__sprintf+86>
=> 0x00007ffff718290f <+31>:    movaps %xmm0,0x50(%rsp)
   0x00007ffff7182914 <+36>:    movaps %xmm1,0x60(%rsp)
   0x00007ffff7182919 <+41>:    movaps %xmm2,0x70(%rsp)
   0x00007ffff718291e <+46>:    movaps %xmm3,0x80(%rsp)
   0x00007ffff7182926 <+54>:    movaps %xmm4,0x90(%rsp)
   0x00007ffff718292e <+62>:    movaps %xmm5,0xa0(%rsp)
   0x00007ffff7182936 <+70>:    movaps %xmm6,0xb0(%rsp)
   0x00007ffff718293e <+78>:    movaps %xmm7,0xc0(%rsp)
   0x00007ffff7182946 <+86>:    lea    0xe0(%rsp),%rax
   0x00007ffff718294e <+94>:    lea    0x8(%rsp),%rdx
   0x00007ffff7182953 <+99>:    mov    %rax,0x10(%rsp)
   0x00007ffff7182958 <+104>:   lea    0x20(%rsp),%rax
   0x00007ffff718295d <+109>:   movl   $0x10,0x8(%rsp)
   0x00007ffff7182965 <+117>:   movl   $0x30,0xc(%rsp)
   0x00007ffff718296d <+125>:   mov    %rax,0x18(%rsp)
   0x00007ffff7182972 <+130>:   callq  0x7ffff719d0a0 <__IO_vsprintf>
   0x00007ffff7182977 <+135>:   add    $0xd8,%rsp
   0x00007ffff718297e <+142>:   retq   
End of assembler dump.

-- 
You are receiving this mail because:
You are on the CC list for the bug.