Some more analysis: We enter libc from openssh code with the correct values in rsi and rdi:
(gdb) u => 0x56560e45 <main+12661>: call 0x5655d0b0 <setgroups@plt> (gdb) info r rax 0xfffe 65534 rbx 0x5663a000 1449369600 rcx 0x0 0 rdx 0x0 0 rsi 0xffffd2e0 4294955744 rdi 0x1 1 rbp 0x56641b50 1449401168 rsp 0xffffd260 4294955616 r8 0x0 0 r9 0x0 0 r10 0xf7a88888 4155017352 r11 0x246 582 r12 0x565d71d1 1448964561 r13 0x3 3 r14 0xe2cc 58060 r15 0x5663c730 1449379632 rip 0x56560e45 1448480325 eflags 0x282 [ SF IF ] cs 0x33 51 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 Inside glibc, there’s an indirect call: => 0xf79949f4 <__GI_setgroups+100>: call rax rax 0xf7833500 4152571136 => 0xf7833500 <__nptl_setxid>: push r15 Some time in __nptl_setxid later, here’s the bug: 1162 in allocatestack.c rax 0xf77ca840 4152141888 rbx 0xffffd230 4294955568 rcx 0x0 0 rdx 0x1 1 rsi 0xffffd2e0 4294955744 rdi 0xf77ca840 4152141888 rbp 0xf77ca840 4152141888 rsp 0xffffd1d0 4294955472 r8 0x0 0 r9 0x0 0 r10 0xf77caac0 4152142528 r11 0x246 582 r12 0xf784a360 4152664928 r13 0xf784a360 4152664928 r14 0xf78482c8 4152656584 r15 0x400000ca 1073742026 rip 0xf7833752 4152571730 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 => 0xf7833752 <__nptl_setxid+594>: movsxd rsi,DWORD PTR [ebx+0x8] 0xf7833757 <__nptl_setxid+599>: movsxd rdi,DWORD PTR [ebx+0x4] 0xf783375c <__nptl_setxid+604>: movsxd rdx,DWORD PTR [ebx+0xc] (gdb) t => 0xf7833752 <__nptl_setxid+594>: movsxd rsi,DWORD PTR [ebx+0x8] 1162 in allocatestack.c rax 0xf77ca840 4152141888 rbx 0xffffd230 4294955568 rcx 0x0 0 rdx 0x1 1 rsi 0xffffffffffffd2e0 -11552 rdi 0xf77ca840 4152141888 rbp 0xf77ca840 4152141888 rsp 0xffffd1d0 4294955472 r8 0x0 0 r9 0x0 0 r10 0xf77caac0 4152142528 r11 0x246 582 r12 0xf784a360 4152664928 r13 0xf784a360 4152664928 r14 0xf78482c8 4152656584 r15 0x400000ca 1073742026 rip 0xf7833757 4152571735 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 Looking at the next instructions… => 0xf7833757 <__nptl_setxid+599>: movsxd rdi,DWORD PTR [ebx+0x4] 0xf783375c <__nptl_setxid+604>: movsxd rdx,DWORD PTR [ebx+0xc] 0xf7833761 <__nptl_setxid+609>: mov eax,DWORD PTR [ebx] 0xf7833764 <__nptl_setxid+612>: syscall … this most likely corresponds to this C source: 1162 result = INTERNAL_SYSCALL_NCS (cmdp->syscall_no, err, 3, 1163 cmdp->id[0], cmdp->id[1], cmdp->id[2]); Diffing glibc-2.30..glibc-2.31 shows no noticeable delta in nptl/allocatestack.c so going on. struct xid_command (nptl/descr.h) also did not change. Looking at pthread_create.o (whyever this is the file __nptl_setxid ends up being in) from 2.30-8, the code in question looks like this: c3d: 67 8b 75 08 mov esi,DWORD PTR [ebp+0x8] c41: 67 8b 7d 04 mov edi,DWORD PTR [ebp+0x4] c45: 67 8b 55 0c mov edx,DWORD PTR [ebp+0xc] c49: 67 8b 45 00 mov eax,DWORD PTR [ebp+0x0] c4d: 0f 05 syscall So something clearly changed… //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg