[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100214144415.GA8115@x200>
Date: Sun, 14 Feb 2010 16:44:15 +0200
From: Alexey Dobriyan <adobriyan@...il.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org, herbert@...dor.apana.org.au
Subject: [PATCH] ipcomp: double free at ipcomp_destroy()
Consider using ipcomp with tunnel mode:
pfkey_add -> xfrm_state_init -> x->type->init_state() == ipcomp4_init_state
1. If ipcomp_tunnel_attach() fails, xfrm_state private data (x->data) are freed
first time (synchronously), but stale pointer is left.
2. xfrm_state_init() failed, all right, we're going to do error unwind
but this time asynchronously and we're going to double free x->data
asynchronously.
Fix by clearing x->data pointer, so second time it'll be fine.
Note, second time can happen in quite arbitrary time, double free
messages were seen in completely irrelevant functions, e. g.
INFO: Allocated in icmp_sk_init
INFO: Freed in icmp_sk_exit
[<ffffffff810b5ceb>] kfree+0xab/0x140
[<ffffffff810719ae>] free_sect_attrs (!)
[<ffffffff81072353>] free_module
The only common thing was kmalloc-16 cache.
Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
---
net/xfrm/xfrm_ipcomp.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -332,6 +332,7 @@ void ipcomp_destroy(struct xfrm_state *x)
ipcomp_free_data(ipcd);
mutex_unlock(&ipcomp_resource_mutex);
kfree(ipcd);
+ x->data = NULL;
}
EXPORT_SYMBOL_GPL(ipcomp_destroy);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists