Commit d10920ba authored by Herbert Xu's avatar Herbert Xu Committed by David S. Miller

[IPSEC]: Fix xfrm_tunnel leak.

Turns out that the IPIP tunnel used by IPCOMP states are only freed
if the IPCOMP state is deleted by xfrm_state_delete.

This is not the case for all states.  For example, an immature IPCOMP
state that dies in add_sa will not go through xfrm_state_delete.

The following patch moves the delete_tunnel call into IPCOMP's
destructor.  I think it makes more sense there as IPCOMP is the
only user of the tunnel anyway.
parent aaecbc98
...@@ -339,6 +339,7 @@ static void ipcomp_destroy(struct xfrm_state *x) ...@@ -339,6 +339,7 @@ static void ipcomp_destroy(struct xfrm_state *x)
struct ipcomp_data *ipcd = x->data; struct ipcomp_data *ipcd = x->data;
if (!ipcd) if (!ipcd)
return; return;
xfrm_state_delete_tunnel(x);
ipcomp_free_data(ipcd); ipcomp_free_data(ipcd);
kfree(ipcd); kfree(ipcd);
} }
......
...@@ -231,7 +231,6 @@ static void __xfrm_state_delete(struct xfrm_state *x) ...@@ -231,7 +231,6 @@ static void __xfrm_state_delete(struct xfrm_state *x)
void xfrm_state_delete(struct xfrm_state *x) void xfrm_state_delete(struct xfrm_state *x)
{ {
xfrm_state_delete_tunnel(x);
spin_lock_bh(&x->lock); spin_lock_bh(&x->lock);
__xfrm_state_delete(x); __xfrm_state_delete(x);
spin_unlock_bh(&x->lock); spin_unlock_bh(&x->lock);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment