Dixi quod…
>ara2:~# cat >x.c
>#include <netinet/in.h>
>#include <arpa/nameser.h>
>#include <resolv.h>
>
>int
>main(void)
>{
> return (res_init());
>}
>ara2:~# gcc x.c
>ara2:~# ./a.out
>Segmentation fault
>Basically, the segfault is on accessing _res.retrans
>in line 67 (first access of _res)
Now, _res is at 0xc014ce58 and the code in question is:
0xc00f1eb4 <__res_init>: linkw %fp,#0
0xc00f1eb8 <__res_init+4>: moveml %d2-%d5/%a2/%a5,%sp@-
0xc00f1ebc <__res_init+8>: lea %pc@(0xc0148000),%a5
0xc00f1ec4 <__res_init+16>: movel %a5,%d5
0xc00f1ec6 <__res_init+18>: addil #9916,%d5
0xc00f1ecc <__res_init+24>: movel %d5,%sp@-
0xc00f1ece <__res_init+26>: movel %d5,%sp@
0xc00f1ed0 <__res_init+28>: bsrl 0xc0040aa0 <__tls_get_addr@plt>
0xc00f1ed6 <__res_init+34>: addql #4,%sp
=> 0xc00f1ed8 <__res_init+36>: moveal %a0@,%a2
0xc00f1eda <__res_init+38>: tstl %a2@
0xc00f1edc <__res_init+40>: bnes 0xc00f1ee2 <__res_init+46>
0xc00f1ede <__res_init+42>: moveq #5,%d0
0xc00f1ee0 <__res_init+44>: movel %d0,%a2@
0xc00f1ee2 <__res_init+46>: tstl %a2@(4)
0xc00f1ee6 <__res_init+50>: bnes 0xc00f1eee <__res_init+58>
0xc00f1ee8 <__res_init+52>: moveq #4,%d1
0xc00f1eea <__res_init+54>: movel %d1,%a2@(4)
0xc00f1eee <__res_init+58>: btst #0,%a2@(11)
0xc00f1ef4 <__res_init+64>: bnes 0xc00f1f5a <__res_init+166>
The access happens with:
a0 0xc0021be1 0xc0021be1
a2 0x0 0x0
If I read that right, it’s the equivalent of: mov a2,dword ptr [a0]
So, question, why does that access out-of-bounds memory? This is
apparently introduced with TLS support.
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0xc00021d8 0xc00148b0 Yes /lib/ld.so.1
0xc0040adc 0xc011ba62 Yes /lib/libc.so.6
According to "info target" there’s nothing there:
[…]
0xc001d05c - 0xc001d120 is .bss in /lib/ld.so.1
0xc0022174 - 0xc0022198 is .note.gnu.build-id in /lib/libc.so.6
[…]
bye,
//mirabilos
--
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 22:21⎜<mksh> it’s a
very thin line anyway… with some, you don’t know which side they’re on
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1101302028040.30...@herc.mirbsd.org
