[Openswan dev] Memory leak in klips:ipsec_rcv (klips 2.4.7, kernel 2.4.33)

[Wolfgang Nothdurft]

Hi,

I have seen the same issue reported on Nov 2006 ( 
http://lists.openswan.org/pipermail/dev/2006-November/001483.html).

On two different machines the memory runs out in short time and 
/proc/slabinfo shows that most of the memory is used by the size-2048 cache.

On the first machine the memory leak was mainly caused by duplicate 
frames, during a rekeying:

May  6 16:56:51 defendo kernel: klips_debug:ipsec_rcv: duplicate frame 
from xxx.xxx.xxx.xxx, packet dropped
May  6 16:56:51 defendo kernel: klips_debug:ipsec_rcv: decap_once 
failed: -15
May  6 16:56:51 defendo kernel: klips_debug:ipsec_rcv: suspected 
ESPinUDP packet (NAT-Traversal) [2].
-Traversal) [2].

The second machine leaks on bogus packet and incomplete policy, but not 
  in combination with a rekeying like the other machine:

May 20 11:23:17 defendo kernel: klips_debug:ipsec_rcv: trimming to -103.
May 20 11:23:17 defendo kernel: klips_debug:ipsec_rcv: bogus packet, 
size is zero or negative, dropping.
May 20 11:23:17 defendo kernel: klips_debug:ipsec_rcv: decap_once failed: -6
May 20 11:23:17 defendo kernel: klips_debug:ipsec_rcv: <<< Info -- 
skb->dev=ppp0 dev=ppp0

May 20 11:49:36 defendo kernel: klips_debug: IP: ihl:20 ver:4 tos:0 
tlen:74 id:0 frag_off:0 ttl:123 proto:0 chk:51507 saddr:xxx.xxx.xxx.xxx 
daddr:xxx.xxx.xxx.xxx
May 20 11:49:36 defendo kernel: klips_debug:ipsec_rcv: packet with 
incomplete policy dropped, last successful SA:esp.xxxxxxx at xxx.xxx.xxx.xxx.
May 20 11:49:36 defendo kernel: klips_debug:ipsec_rcv: decap_once 
failed: -12
May 20 11:49:36 defendo kernel: klips_debug:ipsec_rcv: <<< Info -- 
skb->dev=ppp0 dev=ppp0

This bug seems to be in all versions up to 2.4.12/2.5.17, cause I can't 
see any changes in the code regarding the problem.

I have no test system where I can reproduce the error at the moment, 
because both machines are production systems.
I only have a test system where I turned around the if query, so that 
problem appears permanently. With the fix the system runs stable at the 
moment and no mem leak appears.

Is there a reason why this bug is ignored?
Is the fix the user reported, to assign the irs->skb to skb before goto 
rcvleave save?

Thanks,
Wolfgang