[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1216905812.5897.6.camel@penberg-laptop>
Date: Thu, 24 Jul 2008 16:23:32 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Patrick McHardy <kaber@...sh.net>
Cc: Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
herbert@...dor.apana.org.au, w@....eu, davidn@...idnewall.com,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
stefanr@...6.in-berlin.de, rjw@...k.pl, ilpo.jarvinen@...sinki.fi,
Dave Jones <davej@...hat.com>
Subject: Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL
pointer dereference
On Thu, 2008-07-24 at 14:49 +0200, Patrick McHardy wrote:
> Pekka Enberg wrote:
> > On Thu, Jul 24, 2008 at 3:03 PM, Patrick McHardy <kaber@...sh.net> wrote:
> >> Ingo Molnar wrote:
> >>> * Ingo Molnar <mingo@...e.hu> wrote:
> >>>
> >>>> here's a new type of crash a -tip testbox triggered today:
> >>>>
> >>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> >>>> IP: [<0000000000000000>] 0x0
> >>>> ...
> >>>> Call Trace:
> >>>> [<ffffffff80777f25>] ? ipv4_confirm+0x8d/0x122
> >>>> [<ffffffff80733107>] nf_iterate+0x43/0xa5
> >> Does reverting 31d8519c fix this?
> >
> > Hmm, why do you think it's related? It looks like elem->hook() is a
> > NULL pointer but my patch shouldn't make any difference here...
>
> No, its already in ipv4_confirm, so its most likely helper->help()
> thats NULL, which is contained in an extension.
>
> The reason why I think its this patch is (quoting from an old
> email that I never got a response to):
Oh, I'm really sorry about that.
> ---
> Your patch introduced a use-after-free and double-free.
> krealloc() frees the old pointer, but it is still used
> for the ->move operations, then freed again.
>
> To fix this I think we need a __krealloc() that doesn't
> free the old memory, especially since it must not be
> freed immediately because it may still be used in a RCU
> read side (see the last part in the patch attached to
> this mail (based on a kernel without your patch)).
Agreed. Something like this, perhaps?
[PATCH] netfilter: fix double-free and use-after free
As suggested by Patrick McHardy, introduce a __krealloc() that doesn't
free the original buffer to fix a double-free and use-after-free bug
introduced by me in netfilter that uses RCU.
Reported-by: Patrick McHardy <kaber@...sh.net>
Signed-off-by: Pekka Enberg <penberg@...helsinki.fi>
---
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9aa90a6..be6f1d4 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -96,6 +96,7 @@ int kmem_ptr_validate(struct kmem_cache *cachep, const void *ptr);
/*
* Common kmalloc functions provided by all allocators
*/
+void * __must_check __krealloc(const void *, size_t, gfp_t);
void * __must_check krealloc(const void *, size_t, gfp_t);
void kfree(const void *);
size_t ksize(const void *);
diff --git a/mm/util.c b/mm/util.c
index 8f18683..6ef9e99 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -68,25 +68,22 @@ void *kmemdup(const void *src, size_t len, gfp_t gfp)
EXPORT_SYMBOL(kmemdup);
/**
- * krealloc - reallocate memory. The contents will remain unchanged.
+ * __krealloc - like krealloc() but don't free @p.
* @p: object to reallocate memory for.
* @new_size: how many bytes of memory are required.
* @flags: the type of memory to allocate.
*
- * The contents of the object pointed to are preserved up to the
- * lesser of the new and old sizes. If @p is %NULL, krealloc()
- * behaves exactly like kmalloc(). If @size is 0 and @p is not a
- * %NULL pointer, the object pointed to is freed.
+ * This function is like krealloc() except it never frees the originally
+ * allocated buffer. Use this if you don't want to free the buffer immediately
+ * like, for example, with RCU.
*/
-void *krealloc(const void *p, size_t new_size, gfp_t flags)
+void *__krealloc(const void *p, size_t new_size, gfp_t flags)
{
void *ret;
size_t ks = 0;
- if (unlikely(!new_size)) {
- kfree(p);
+ if (unlikely(!new_size))
return ZERO_SIZE_PTR;
- }
if (p)
ks = ksize(p);
@@ -95,10 +92,37 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags)
return (void *)p;
ret = kmalloc_track_caller(new_size, flags);
- if (ret && p) {
+ if (ret && p)
memcpy(ret, p, ks);
+
+ return ret;
+}
+EXPORT_SYMBOL(__krealloc);
+
+/**
+ * krealloc - reallocate memory. The contents will remain unchanged.
+ * @p: object to reallocate memory for.
+ * @new_size: how many bytes of memory are required.
+ * @flags: the type of memory to allocate.
+ *
+ * The contents of the object pointed to are preserved up to the
+ * lesser of the new and old sizes. If @p is %NULL, krealloc()
+ * behaves exactly like kmalloc(). If @size is 0 and @p is not a
+ * %NULL pointer, the object pointed to is freed.
+ */
+void *krealloc(const void *p, size_t new_size, gfp_t flags)
+{
+ void *ret;
+
+ if (unlikely(!new_size)) {
kfree(p);
+ return ZERO_SIZE_PTR;
}
+
+ ret = __krealloc(p, new_size, flags);
+ if (ret && p != ret)
+ kfree(p);
+
return ret;
}
EXPORT_SYMBOL(krealloc);
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index 3469bc7..c956ef7 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -95,7 +95,7 @@ void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
newlen = newoff + t->len;
rcu_read_unlock();
- new = krealloc(ct->ext, newlen, gfp);
+ new = __krealloc(ct->ext, newlen, gfp);
if (!new)
return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists