linux-kernel - Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jul 2008 14:13:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Patrick McHardy <kaber@...sh.net>
cc:	Pekka Enberg <penberg@...helsinki.fi>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>,
	herbert@...dor.apana.org.au, w@....eu, davidn@...idnewall.com,
	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, 24 Jul 2008, Patrick McHardy wrote:
> 
> 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)).

Hmm. Don't you need to fix some of the ordering of the initialization too?

If there are possible readers that happen in parallel with changing this 
thing, don't you need to protect the update of "ext->len" against the 
actual changes? And the readers should probably have a read barrier 
between checking "len" and actually looking at the values? Finally, why do 
the "ct->ext" dereference thing, when we know it has to be equal to "new"?

ie something like this on the writing side (in _addition_ to both the 
patches already seen), but I didn't do the reading side (ie there are no 
"smp_rmb()"'s on the reading side)

And no, I don't know the code, so I don't know who/what can read those 
things with RCU, so maybe there is some reason why the actual data doesn't 
need protecting. But I somehow doubt it.

		Linus

---
 net/netfilter/nf_conntrack_extend.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index 3469bc7..135e095 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -115,10 +115,11 @@ void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
 		ct->ext = new;
 	}
 
-	ct->ext->offset[id] = newoff;
-	ct->ext->len = newlen;
-	memset((void *)ct->ext + newoff, 0, newlen - newoff);
-	return (void *)ct->ext + newoff;
+	new->offset[id] = newoff;
+	memset((void *)new + newoff, 0, newlen - newoff);
+	smp_wmb();
+	new->len = newlen;
+	return (void *)new + newoff;
 }
 EXPORT_SYMBOL(__nf_ct_ext_add);
 
--
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/