[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]



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


Reply to: