[Openswan Users] keeping SA made OCF resource leak

[David McCullough]

Jivin Martin Schiller lays it down ...
> ----- Original Message ----- 
> From: "David McCullough"
> Sent: Friday, July 31, 2009 12:53 AM
> 
> 
> > That is correct.  AFAICT now,  pluto is not releasing all the SA's correctly
> > on a rekey,  still working through it.
> 
> I've got a similar problem here since I have updated from openswan 2.4.14 to 2.6.22:
> 
> When I set up (ipsec auto --up) a very simply MainMode PSK connection between 2 machines, I am 
> getting the following output:
> 
> root:~# ipsec spi
> tun0x1001 at 10.1.3.28 IPIP: dir=out src=10.1.4.165 life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 
> natdport=0 refcount=2 ref=1 refhim=0 reftable=0 refentry=1
> tun0x1002 at 10.1.4.165 IPIP: dir=in  src=10.1.3.28 policy=192.168.28.0/24->192.168.165.0/24 
> flags=0x8<> life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=3 ref=3 refhim=1 
> reftable=0 refentry=3
> esp0x54151c68 at 10.1.4.165 ESP_AES_HMAC_SHA1: dir=in  src=10.1.3.28 iv_bits=128bits 
> iv=0x574f2a911105bab302e3e52117b0f6ad ooowin=64 alen=160 aklen=160 eklen=128 
> life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=2 ref=4 refhim=1 reftable=0 
> refentry=4
> esp0x4d313dc7 at 10.1.3.28 ESP_AES_HMAC_SHA1: dir=out src=10.1.4.165 iv_bits=128bits 
> iv=0xf8fb7431dd25d6b8e1b0bc69dc2fd179 ooowin=64 alen=160 aklen=160 eklen=128 
> life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=3 ref=2 refhim=0 reftable=0 
> refentry=2
> 
> When I then do an ipsec auto --down (on the initiator side) and check the output of ipsec spi once 
> again, I can see that:
> 
> root:~# ipsec spi
> tun0x1001 at 10.1.3.28 IPIP: dir=out src=10.1.4.165 life(c,s,h)=addtime(6,0,0) natencap=none natsport=0 
> natdport=0 refcount=2 ref=1 refhim=0 reftable=0 refentry=1
> tun0x1002 at 10.1.4.165 IPIP: dir=in  src=10.1.3.28 policy=192.168.28.0/24->192.168.165.0/24 
> flags=0x8<> life(c,s,h)=addtime(6,0,0) natencap=none natsport=0 natdport=0 refcount=2 ref=3 refhim=1 
> reftable=0 refentry=3
> 
> And if i wait some time, so that there could happen some rekeyings, the amount of tun* SAs are 
> increasing but none is ever deleted.
> 
> So, It seems to me that tun* SAs will never be deleted in general.
> 
> That wasn't so in the openswan 2.4.x releases and I think it has something to to with the way the 
> SAs are deleted in the ipsec_sa_rm() function.
> In 2.4.x there was an ipsec_sa_delchain() instead, in which you can find the following code
> 
>  while(ips->ips_onext != NULL) {
>   ips = ips->ips_onext;
>  }
> 
> where ips_onext points the the previous entry in the chain.
> 
> If I am right, this means that we are jumping to the first entry in the chain before we start 
> removing SAs.
> I cannot find an equivalent of this in the 2.6.x code.

I have a patch in the working for this now.

The problem spreads across user/kernel space.

pluto loads each SA individually and then "groups" them.  On delete,
because they are grouped,  it expects to be abel to delete any of the SA's
and take out the whole group.

Basically the kernel code was not:

	1) dereferencing the whole group (So the SA counts were wrong)
	2) not finding all the members in the group proplerly
	3) a few other refcount bugs on the way :-(

I'll be testing this heavily over the weekend and I'll post a patch as soon
as I have it cleaned up.

I have yet to confirm that this is also causing the DPD problems that others
are reporting.

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org