[Openswan dev] free_sa() crasher with LEAK_DETECTIVE, could use another eye ball

Paul Wouters paul at xelerance.com
Tue Jul 12 13:05:21 EDT 2011

If you compile with LEAK_DETECTIVE=yes and use compress=yes in your conn, we crash on what
looks like a double pfree()

(gdb) bt
#0  0x00007f31498d4945 in raise (sig=6)
     at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f31498d6125 in abort () at abort.c:92
#2  0x00007f314b95d6c2 in openswan_log_abort (
     file_str=0x7f314ba30ba0 "/builddir/build/BUILD/openswan-2.6.34/lib/libopenswan/alloc.c", line_no=138)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/log.c:536
#3  0x00007f314b95da53 in passert_fail (
     pred_str=0x7f314ba30c0e "p->i.magic == LEAK_MAGIC",
     file_str=0x7f314ba30ba0 "/builddir/build/BUILD/openswan-2.6.34/lib/libopenswan/alloc.c", line_no=138)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/log.c:636
#4  0x00007f314b9e544e in leak_pfree (ptr=0x7f3144b2afe8, leak=1)
     at /usr/src/debug/openswan-2.6.34/lib/libopenswan/alloc.c:138
#5  0x00007f314b9b1db1 in free_sa_prop (dp=0x7f3144b2cfe8)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/spdb.c:989
#6  0x00007f314b9b1e76 in free_sa_prop_conj (pc=0x7f3144ad9ff0)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/spdb.c:1012
#7  0x00007f314b9b1f58 in free_sa (f=0x7f3144ad7fd8)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/spdb.c:1038
#8  0x00007f314b9b3d8a in out_sa (outs=0x7fff91f7a6c0, sadb=0x7f3144ad7fd8,
     st=0x7f3144cdb888, oakley_mode=0, aggressive_mode=0, np=10 '\n')
     at /usr/src/debug/openswan-2.6.34/programs/pluto/spdb_v1_struct.c:509
---Type <return> to continue, or q <return> to quit---
#9  0x00007f314b97d89b in quick_outI1_tail (pcrc=0x7f3144ad3f60,
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1_quick.c:905
#10 0x00007f314b97cffe in quick_outI1_continue (pcrc=0x7f3144ad3f60,
     r=0x7fff91f7a870, ugh=0x0)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1_quick.c:735
#11 0x00007f314b9a8399 in send_crypto_helper_request (r=0x7fff91f7a870,
     cn=0x7f3144ad3f60, toomuch=0x7fff91f7a86c)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/pluto_crypt.c:416
#12 0x00007f314b9aa34e in build_ke (cn=0x7f3144ad3f60, st=0x7f3144cdb888,
     group=0x7f314bc51ae0, importance=pcim_demand_crypto)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/crypt_ke.c:211
#13 0x00007f314b97d4e3 in quick_outI1 (whack_sock=-1,
     isakmp_sa=0x7f3144db9888, c=0x7f31458dcbb8, policy=2181103734, try=1,
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1_quick.c:828
#14 0x00007f314b9595a6 in unpend (st=0x7f3144db9888)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/pending.c:197
#15 0x00007f314b9738d8 in complete_v1_state_transition (mdp=0x7f314bc5be88,
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1.c:2303
#16 0x00007f314b972233 in process_packet_tail (mdp=0x7f314bc5be88)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1.c:1855
---Type <return> to continue, or q <return> to quit---
#17 0x00007f314b971177 in process_v1_packet (mdp=0x7f314bc5be88)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/ikev1.c:1397
#18 0x00007f314b9a219b in process_packet (mdp=0x7f314bc5be88)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/demux.c:163
#19 0x00007f314b9a2227 in comm_handle (ifp=0x7f3144d8dfc0)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/demux.c:212
#20 0x00007f314b968357 in call_server ()
     at /usr/src/debug/openswan-2.6.34/programs/pluto/server.c:764
#21 0x00007f314b964e79 in main (argc=13, argv=0x7fff91f7c498)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/plutomain.c:1055
(gdb) f 5
#5  0x00007f314b9b1db1 in free_sa_prop (dp=0x7f3144b2cfe8)
     at /usr/src/debug/openswan-2.6.34/programs/pluto/spdb.c:989
989		pfree(dp->trans);
(gdb) p dp->trans
$4 = (struct db_trans *) 0x7f3144b2afe8
(gdb) p *dp->trans
$5 = {transid = 2, attrs = 0x0, attr_cnt = 0}
(gdb) f 4
#4  0x00007f314b9e544e in leak_pfree (ptr=0x7f3144b2afe8, leak=1)
     at /usr/src/debug/openswan-2.6.34/lib/libopenswan/alloc.c:138
138		passert(p->i.magic == LEAK_MAGIC);
(gdb) p p
$6 = (union mhdr *) 0x7f3144b2afc0
(gdb) p *p
$7 = {i = {name = 0x0, older = 0x0, newer = 0x0, magic = 0, size = 0},
   junk = 0}

This is not a double pfree() because the magic should then be !LEAK_MAGIC,
while it is 0. (It could be a free() though that's untracked)

Linking with efence showed that we did not scribble over the end of
a variable, because it never got triggered. Setting EF_PROTECT_BELOW=1
also showed we did not scribble over the beginning. I also tested with

Looking at the code:

free_sa(struct db_sa *f)
     unsigned int i;
     if(f == NULL) return;

     for(i=0; i<f->prop_conj_cnt; i++) {
     if(f->prop_conjs) {

free_sa calls free_sa_prop_conj():

free_sa_prop_conj(struct db_prop_conj *pc)
     unsigned int i;
     for(i=0; i<pc->prop_cnt; i++) {
     if(pc->props) {

which loops over free_sa_prop():

free_sa_prop(struct db_prop *dp)
     unsigned int i;
     for(i=0; i<dp->trans_cnt; i++) {
     if(dp->trans) {
         pfree(dp->trans);     <---- this is the bad pfree

which loops over free_sa_trans():

free_sa_trans(struct db_trans *tr)
     if(tr->attrs) {

The crash happens in the pfree() in free_sa_prop()

I then tried to use EF_FILL=1 and reran:

then I got:

(gdb) f 4
#4  0x0000000000486d47 in leak_pfree (ptr=0xb02310, leak=1)
     at /root/openswan-2.6.35dr1/lib/libopenswan/alloc.c:138
138		passert(p->i.magic == LEAK_MAGIC);
(gdb) p p 
$1 = (union mhdr *) 0xb022e8
(gdb) p *p 
$2 = {i = {
     name = 0xdb0be6ec813a0a35 <Address 0xdb0be6ec813a0a35 out of bounds>,
     older = 0x779b8b6d8d22cf2a, newer = 0x180000142e17ed1b,
     magic = 16044425180566980584, size = 49}, junk = 15783963222504770101}

and using EF_FILL=254:

(gdb) p *p
$1 = {i = {name = 0x1a6ed58 "\002", older = 0x1a6bda8, newer = 0x0, magic = 0,
     size = 33}, junk = 27716952}

I tried without setting EF_FILL and also got different values, but magic =0.
I am not sure if this is LEAK_DETECTIVE and efence fighting?

When not using LEAK_DETECTIVE and only efence, I get no crasher, with or withut

So I'm left somewhat confused,


More information about the Dev mailing list