Re: Possible netfilter-related memory corruption in 2.6.37

[Patrick McHardy <kaber@trash.net>]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Am 14.02.2011 17:52, schrieb Patrick McHardy:
> Am 14.02.2011 17:48, schrieb Eric Dumazet:
>> I am not sure, but I guess nf_reinject() needs a fix too ;)
> 
> I agree. That one looks uglier though, I guess we'll have to
> iterate through all hooks to note the previous one.

How about this? Unfortunately I don't think we can avoid
iterating through all hooks without violating RCU rules.



[-- Attachment #2: x.diff --]
[-- Type: text/plain, Size: 1009 bytes --]

diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index 74aebed..834bb07 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -235,6 +235,7 @@ int nf_queue(struct sk_buff *skb,
 void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
 {
 	struct sk_buff *skb = entry->skb;
+	struct nf_hook_ops *i, *prev;
 	struct list_head *elem = &entry->elem->list;
 	const struct nf_afinfo *afinfo;
 
@@ -244,8 +245,21 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
 
 	/* Continue traversal iff userspace said ok... */
 	if (verdict == NF_REPEAT) {
-		elem = elem->prev;
-		verdict = NF_ACCEPT;
+		prev = NULL;
+		list_for_each_entry_rcu(i, &nf_hooks[entry->pf][entry->hook],
+					list) {
+			if (&i->list == elem)
+				break;
+			prev = i;
+		}
+
+		if (prev == NULL ||
+		    &i->list == &nf_hooks[entry->pf][entry->hook])
+			verdict = NF_DROP;
+		else {
+			elem = &prev->list;
+			verdict = NF_ACCEPT;
+		}
 	}
 
 	if (verdict == NF_ACCEPT) {