search

xelerance / Openswan

Openswan
Other
852 stars 214 forks source link

2.6.51.5 pluto Segmentation fault #399

Closed AnatoliChe closed 4 years ago

AnatoliChe commented 5 years ago

Hi! I have segfault very 3-12 hours :-( Sep 24 20:35:22 kernel: : pluto[24235]: segfault at 1b4 ip 004a95c6 sp bfadc4e0 error 4 in pluto[454000+f8000]

Last what I can see in the log with plutodebug=all:

| helper 0 has finished work (cnt now 1) | helper 0 replies to id: q#918 | calling callback function 0x48f1c0 | quick inI1_outR1: calculated ke+nonce, calculating DH | processing connection peerK-peerD1 | ***emit ISAKMP Hash Payload: | emitting 20 zero bytes of HASH into ISAKMP Hash Payload | emitting length of ISAKMP Hash Payload: 24 | HASH(3) computed: db ef 3b 5f 28 3a 2e 5a 3a 52 46 f5 3c 53 a7 7e | HASH(3) computed: b8 71 8d 7f | compute_proto_keymat:needed_len (after ESP enc)=16 | compute_proto_keymat:needed_len (after ESP auth)=16 | ESP KEYMAT | KEYMAT computed: | 6f fa d8 1f 73 93 48 a4 d0 4d f3 12 23 77 e4 cb | Peer KEYMAT computed: | 0d a7 92 b7 3f 15 64 45 62 21 43 5f 80 87 06 00 | state #455: install_ipsec_sa() for inbound and outbound | route owner of "peerK-peerD1" erouted: self; eroute owner: self | could_route called for peerK-peerD1 (kind=CK_PERMANENT) | state #455: now setting up incoming SA pluto_crypto_helper: helper [nonnss] (2) is exiting normally pluto_crypto_helper: helper [nonnss] (0) is exiting normally Segmentation fault (core dumped) pluto_crypto_helper: helper [nonnss] (1) is exiting normally

I tried backtrace core dump `#gdb /usr/local/libexec/ipsec/pluto -c core-pluto.24235.1569346522 Reading symbols from /usr/local/libexec/ipsec/pluto...done.

warning: no loadable sections found in added symbol-file system-supplied DSO at 0xb7753000 Core was generated by `/usr/local/libexec/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipse'. Program terminated with signal 11, Segmentation fault.

0 0x004a95c6 in ?? ()

(gdb) bt

0 0x004a95c6 in ?? ()

1 0x004ad19a in ?? ()

2 0x0048ec74 in ?? ()

3 0x0048f272 in ?? ()

4 0x004c0f03 in ?? ()

5 0x004c1188 in ?? ()

6 0x0047a1ff in ?? ()

7 0x004770fe in ?? ()

8 0xb7578c96 in ?? ()

9 0x004610d1 in ?? ()

(gdb) frame 0

0 0x004a95c6 in ?? ()

(gdb) list 343 schedule an event for refresh. 344 / 345 get_rnd_bytes(secret_of_the_day, sizeof(secret_of_the_day)); 346 event_schedule(EVENT_REINIT_SECRET, EVENT_REINIT_SECRET_DELAY, NULL); 347 } 348 349 350 int 351 main(int argc, char **argv) 352 { (gdb) print secret_of_the_day $1 = '\000' <repeats 19 times> (gdb) print sizeof(secret_of_the_day) $2 = 20 `

core dump and pluto are included in this post

Could anyone help?

pluto.gz core.zip

shussain commented 5 years ago

Thank you for the core dump. Can you also provide the content of ipsec barf

AnatoliChe commented 5 years ago

Yes, but not in the public way.

letoams commented 5 years ago

The secret of the day code where this crash seems to happen in takes no user or configuration input, so barf will be meaningless to solve this.

More likely, openswan hasn’t fixed the secret of the day being properly initialized on startup (also btw leading to predictable-ish cookies). This was fixed in libreswan 1-2 years ago. You might want to try and dig up that commit or try libreswan instead

Sent from my iPhone

On Sep 25, 2019, at 08:55, Samir notifications@github.com wrote:

Thank you for the core dump. Can you also provide the content of ipsec barf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

AnatoliChe commented 5 years ago

I tried write some simple hook around this functions to had understanding what was going there. Like: ` init_secret(void) { /*

and can see in debug:

at once after start ` start init_secret secret_of_the_day: '' process init_secret end init_secret in hour: start init_secret secret_of_the_day: '\365p\0327\030\245\306\300\201\263\374B\310\350\355R\350$Jw' process init_secret end init_secret

`

Now waiting next segfault.

AnatoliChe commented 5 years ago

I can see | my_debug start init_secret at 2019-09-27 10:17:50 | my_debug secret_of_the_day: '', at 2019-09-27 10:17:50 | my_debug len of secret_of_the_day: '20' at 2019-09-27 10:17:50 | my_debug process init_secret at 2019-09-27 10:17:50 | my_debug end init_secret at 2019-09-27 10:17:50 | my_debug secret_of_the_day: '\374d\250\177\323\357"@{\037\253\322\252c\371\366G\315_L', at 2019-09-27 10:17:50 | my_debug len of secret_of_the_day: '20' at 2019-09-27 10:17:50 | my_debug end debug at 2019-09-27 10:17:50

so I do not think the problem in secret_of_the_day.

I sure problem in some other place but I can see start code of plutomain.c 'cause I do not have skills in debug of core dumps.