This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/20596] New: sprintf segmentation fault due to misaligned movaps on x86_64
- From: "andrew.thomas at cogent dot ca" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 10 Sep 2016 18:40:18 +0000
- Subject: [Bug libc/20596] New: sprintf segmentation fault due to misaligned movaps on x86_64
- Auto-submitted: auto-generated
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.