Bug 20468 - SIGSEGV in internal_getent on arm64 xenial
Summary: SIGSEGV in internal_getent on arm64 xenial
Status: RESOLVED DUPLICATE of bug 19341
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-14 11:05 UTC by sokoow
Modified: 2016-08-15 19:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sokoow 2016-08-14 11:05:43 UTC
Hey,

I'm running following platform:

ldd (Ubuntu GLIBC 2.23-0ubuntu3) 2.23
ARM64 Odroid C2

and trying to run Drone CI on golang, then I'm getting following SIGSEGV:

Thread 3 "drone" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9a7b2090 (LWP 21950)]
0x0000007f98ddd334 in internal_getent (stream=0x7f840008c0, result=0x6a83ec <net.glob..func11+84>, result@entry=0x2e302e302e373231, 
    buffer=0xca8e08 "gethostbyname4_r", buffer@entry=0x7f9a7b1010 "", buflen=buflen@entry=1064, errnop=0x7f9a7b14c0, errnop@entry=0x7f9a7b15c0, herrnop=0x0, 
    herrnop@entry=0x686c61636f6c0931, af=127, af@entry=0, flags=-1703211040, flags@entry=0) at nss_files/files-XXX.c:251
251	nss_files/files-XXX.c: No such file or directory.
(gdb) bt
#0  0x0000007f98ddd334 in internal_getent (stream=0x7f840008c0, result=0x6a83ec <net.glob..func11+84>, result@entry=0x2e302e302e373231, 
    buffer=0xca8e08 "gethostbyname4_r", buffer@entry=0x7f9a7b1010 "", buflen=buflen@entry=1064, errnop=0x7f9a7b14c0, errnop@entry=0x7f9a7b15c0, herrnop=0x0, 
    herrnop@entry=0x686c61636f6c0931, af=127, af@entry=0, flags=-1703211040, flags@entry=0) at nss_files/files-XXX.c:251
#1  0x0000007f98dde2c0 in _nss_files_gethostbyname4_r (name=0x7f940008c0 "postgres.pharaoh.local", pat=0x7f9a7b15d0, buffer=0x7f9a7b1010 "", buflen=1064, 
    errnop=0x7f9a7b15c0, herrnop=0x686c61636f6c0931, ttlp=<optimized out>) at nss_files/files-hosts.c:392
#2  0x0000000000a71438 in gaih_inet ()
#3  0x0000000000a72ef0 in getaddrinfo ()
#4  0x00000000009b1bec in _cgo_7a2d42f1a351_C2func_getaddrinfo (v=0x442003ba88) at /home/go/src/net/cgo_unix.go:66
#5  0x000000000047cf28 in runtime.asmcgocall () at /home/go/src/runtime/asm_arm64.s:542
#6  0x00000044201716c0 in ?? ()
#7  0x0000000000000001 in ?? ()
Comment 1 sokoow 2016-08-14 11:09:36 UTC
Thread 4 "drone" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f964a1090 (LWP 28090)]
0x0000007f952cc334 in internal_getent (stream=0x7f800008c0, result=0x0, result@entry=0x2e302e302e373231, buffer=0xca8e08 "gethostbyname4_r", 
    buffer@entry=0x7f964a0010 "\200\017F", buflen=buflen@entry=1064, errnop=0x7f964a04c0, errnop@entry=0x7f964a05c0, herrnop=0x0, 
    herrnop@entry=0x686c61636f6c0931, af=127, af@entry=0, flags=-1773535264, flags@entry=0) at nss_files/files-XXX.c:251
251	nss_files/files-XXX.c: No such file or directory.
(gdb) bt
#0  0x0000007f952cc334 in internal_getent (stream=0x7f800008c0, result=0x0, result@entry=0x2e302e302e373231, buffer=0xca8e08 "gethostbyname4_r", 
    buffer@entry=0x7f964a0010 "\200\017F", buflen=buflen@entry=1064, errnop=0x7f964a04c0, errnop@entry=0x7f964a05c0, herrnop=0x0, 
    herrnop@entry=0x686c61636f6c0931, af=127, af@entry=0, flags=-1773535264, flags@entry=0) at nss_files/files-XXX.c:251
#1  0x0000007f952cd2c0 in _nss_files_gethostbyname4_r (name=0x7f880008c0 "repo.pharaoh.local", pat=0x7f964a05d0, buffer=0x7f964a0010 "\200\017F", 
    buflen=1064, errnop=0x7f964a05c0, herrnop=0x686c61636f6c0931, ttlp=<optimized out>) at nss_files/files-hosts.c:392
#2  0x0000000000a71438 in gaih_inet ()
#3  0x0000000000a72ef0 in getaddrinfo ()
#4  0x00000000009b1bec in _cgo_7a2d42f1a351_C2func_getaddrinfo (v=0x4420025d58) at /home/go/src/net/cgo_unix.go:66
#5  0x000000000047cf28 in runtime.asmcgocall () at /home/go/src/runtime/asm_arm64.s:542
#6  0x0000004420421040 in ?? ()
#7  0x0000000000000001 in ?? ()
Comment 2 sokoow 2016-08-14 11:36:05 UTC
I can also reliably reproduce this on amd64 xenial
Comment 3 sokoow 2016-08-14 17:21:50 UTC
(gdb) exploitable
Description: Possible stack corruption
Short description: PossibleStackCorruption (7/22)
Hash: 53cccb5fca1ac9c28753e048e8e80a2b.b10f33ef51e6df44f22c86083d6f159d
Exploitability Classification: EXPLOITABLE
Explanation: GDB generated an error while unwinding the stack and/or the stack contained return addresses that were not mapped in the inferior's process address space and/or the stack pointer is pointing to a location outside the default stack region. These conditions likely indicate stack corruption, which is generally considered exploitable.
Other tags: DestAvNearNull (15/22), AccessViolation (21/22)
Comment 4 Florian Weimer 2016-08-15 09:57:05 UTC
What's the disassembly around the faulting instruction?  Can you show us the register contents, too?

In the past, these things were often bugs in the Go-to-C trampoline code.
Comment 5 sokoow 2016-08-15 16:58:06 UTC
(gdb) info registers
rax            0x7ffff7702648	140737344710216
rbx            0x7fffffff	2147483647
rcx            0x6f6c09312e302e30	8028802342527708720
rdx            0x0	0
rsi            0x7fffe8000b04	140737085704964
rdi            0x7ffff77015a4	140737344705956
rbp            0x7fffe80008c0	0x7fffe80008c0
rsp            0x7ffff7701420	0x7ffff7701420
r8             0x7fffe8000b04	140737085704964
r9             0x7ffff7702648	140737344710216
r10            0x80000	524288
r11            0x246	582
r12            0x7ffff7701590	140737344705936
r13            0x7ffff7701590	140737344705936
r14            0x408	1032
r15            0x31	49
rip            0x7ffff5c82259	0x7ffff5c82259 <internal_getent+233>
eflags         0x10207	[ CF PF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0


asm dump:

   0x00007ffff5c82235 <+197>:	pop    %rbx
   0x00007ffff5c82236 <+198>:	pop    %rbp
   0x00007ffff5c82237 <+199>:	pop    %r12
   0x00007ffff5c82239 <+201>:	pop    %r13
   0x00007ffff5c8223b <+203>:	pop    %r14
   0x00007ffff5c8223d <+205>:	pop    %r15
   0x00007ffff5c8223f <+207>:	retq   
   0x00007ffff5c82240 <+208>:	callq  0x7ffff5c81180 <__ctype_b_loc@plt>
   0x00007ffff5c82245 <+213>:	mov    %r12,%r13
   0x00007ffff5c82248 <+216>:	mov    %rax,%r9
   0x00007ffff5c8224b <+219>:	mov    (%rax),%rdx
   0x00007ffff5c8224e <+222>:	jmp    0x7ffff5c82254 <internal_getent+228>
   0x00007ffff5c82250 <+224>:	add    $0x1,%r13
   0x00007ffff5c82254 <+228>:	movsbq 0x0(%r13),%r15
=> 0x00007ffff5c82259 <+233>:	testb  $0x20,0x1(%rdx,%r15,2)
   0x00007ffff5c8225f <+239>:	mov    %r15,%r14
   0x00007ffff5c82262 <+242>:	jne    0x7ffff5c82250 <internal_getent+224>
   0x00007ffff5c82264 <+244>:	test   %r15b,%r15b
   0x00007ffff5c82267 <+247>:	je     0x7ffff5c821d0 <internal_getent+96>
   0x00007ffff5c8226d <+253>:	cmp    $0x23,%r15b
   0x00007ffff5c82271 <+257>:	je     0x7ffff5c821d0 <internal_getent+96>
   0x00007ffff5c82277 <+263>:	cmp    0x10(%rsp),%r13
   0x00007ffff5c8227c <+268>:	jae    0x7ffff5c824ca <internal_getent+858>
   0x00007ffff5c82282 <+274>:	cmp    %r12,%r13
   0x00007ffff5c82285 <+277>:	jb     0x7ffff5c824ca <internal_getent+858>
   0x00007ffff5c8228b <+283>:	xor    %esi,%esi
   0x00007ffff5c8228d <+285>:	mov    %r13,%rdi
   0x00007ffff5c82290 <+288>:	mov    %r9,0x48(%rsp)
   0x00007ffff5c82295 <+293>:	mov    %rdx,0x40(%rsp)
   0x00007ffff5c8229a <+298>:	callq  0x7ffff5c810c0 <__rawmemchr@plt>
   0x00007ffff5c8229f <+303>:	mov    0x40(%rsp),%rdx
   0x00007ffff5c822a4 <+308>:	mov    0x48(%rsp),%r9
   0x00007ffff5c822a9 <+313>:	add    $0x1,%rax
   0x00007ffff5c822ad <+317>:	mov    %rax,0x30(%rsp)
   0x00007ffff5c822b2 <+322>:	cmp    $0xa,%r14d
   0x00007ffff5c822b6 <+326>:	mov    %r13,%rcx
   0x00007ffff5c822b9 <+329>:	je     0x7ffff5c824e8 <internal_getent+888>
Comment 6 Florian Weimer 2016-08-15 18:17:22 UTC
That's not an arm64 register file or arm64 disassembly.

Is this bug report about aarch64 or x86_64?
Comment 7 sokoow 2016-08-15 18:52:01 UTC
It is happening on both platforms, I can also include aarch64 dump
Comment 8 Florian Weimer 2016-08-15 18:55:36 UTC
(In reply to sokoow from comment #7)
> It is happening on both platforms, I can also include aarch64 dump

Ahh.  Is your Go binary statically linked, by chance?
Comment 9 sokoow 2016-08-15 19:09:07 UTC
I can't see any -static in makefile:

https://github.com/drone/drone/blob/master/Makefile
Comment 10 Florian Weimer 2016-08-15 19:10:13 UTC
Please check the actual binary with file or ldd.  Thanks.
Comment 11 sokoow 2016-08-15 19:40:40 UTC
yup, static
Comment 12 Florian Weimer 2016-08-15 19:49:54 UTC
Crash is in ctype processing, so this is bug 19341.

I don't understand why the Go toolchain makes it so easy to create such broken binaries.

*** This bug has been marked as a duplicate of bug 19341 ***