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

[Wolfgang Nothdurft]

Wolfgang Nothdurft schrieb:
> 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?

The fixed version runs on my test machines and one production system 
(not one of the two critical) for two days now without any problems.
If it runs stable over the weekend, I will try it on the other systems.

I have opened an bugreport with the used patch for this: 
http://bugs.xelerance.com/view.php?id=934

Thanks,
Wolfgang