#34 core dump when running -d -F mode

closed
nobody
None
5
2009-01-16
2005-09-08
Anonymous
No

FreeBSD 4.11 ipsec-tools from ports:

(gdb) bt
#0 0x2829789a in vfprintf () from /usr/lib/libc.so.4
#1 0x2823fb43 in vprintf () from /usr/lib/libc.so.4
#2 0x8085d76 in plogv (pri=5, func=0x80c5c40
"isakmp.c:1736:isakmp_send()", sa=0x0, fmt=0x809b81c
"%zu bytes %s\n", ap=0xbfbff768 "ô") at plog.c:159
#3 0x8085d0c in plog (pri=5, func=0x80c5c40
"isakmp.c:1736:isakmp_send()", sa=0x0, fmt=0x809b81c
"%zu bytes %s\n") at plog.c:140
#4 0x8050629 in isakmp_send (iph1=0x80d3800,
sbuf=0x80df330) at isakmp.c:1736
#5 0x80507db in isakmp_ph1resend (iph1=0x80d3800) at
isakmp.c:1784
#6 0x8057bfe in agg_i1send (iph1=0x80d3800, msg=0x0)
at isakmp_agg.c:283
#7 0x804edc9 in isakmp_ph1begin_i (rmconf=0x80d3600,
remote=0x80df210, local=0x80df220) at isakmp.c:1012
#8 0x8051074 in isakmp_post_acquire (iph2=0x80d3700)
at isakmp.c:2046
#9 0x8067b29 in pk_recvacquire (mhp=0xbfbffa08) at
pfkey.c:1820
#10 0x80648a7 in pfkey_handler () at pfkey.c:265
#11 0x804c56c in session () at session.c:181
#12 0x804c0af in main (ac=5, av=0xbfbffb8c) at main.c:266
(gdb) Quit

darcy@dbitech.ca

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Change the file logger.c and logger.h. In some systems one
    of vfprinf call does not work very well.

    JN

     
  • Hugo Mildenberger

    Logged In: YES
    user_id=1745718
    Originator: NO

    This could be a late effect induced by an off-by one bug in a call to racoon_malloc (about line 380) within splitnet_list_2str in isakmp_unity.c.

    I changed this (within my personal copy) from

    381 str = racoon_malloc(len);

    to

    /* allocate network list string */
    381 str = racoon_malloc(len+1); /* hm: +1 for terminating '\0' character */
    382 if (str == NULL)
    383 return NULL;

    But there is a bunch of other suspicious calls to malloc, called with a size of zero during runtime.

    Another serious off-by one bug is in binsanitize(binstr, n) -- there it can happen a terminating 0 byte will be appended at position q==n, and this, since n defines the allocated buffersize, would by one byte after the end ...

    I changed that too (sorry, no diffs)

    /*
    * hm: was binstr[q++]='\0' ... ->segv when linked with -lefence,
    * since q==n for strings like "Enter Username and Password.",
    * letting thus q point to the character beyond end of allocated
    * buffer space, destroying heap structures eventually.
    */
    if (n) {
    if (q && q < n)
    binstr[q-1] = '\0';
    else
    binstr[n-1] = '\0';
    } else {
    assert(n != 0);
    }

    return binstr;

    Anyway, racoon's memory managment is really a mess -- and needs to be revised urgently. Perhaps one could consider to use fixed length temporary buffers from a sufficiently large circular buffer space, just like ntpd implements it for receive buffers, thus eleminating the dangerous need of mallocs and corresponding free-operations. A temporary solution might be to allocate some additional bytes whenever racoon_malloc or valloc calls malloc, say 20 (I first used 100, until I fixed the bugs mentioned above).

     
  • Timo Teras

    Timo Teras - 2009-01-16

    Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you.

     
  • Timo Teras

    Timo Teras - 2009-01-16
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks