Re: Possible netfilter-related memory corruption in 2.6.37

[Patrick McHardy]

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.



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) {