Thread (12 messages) 12 messages, 4 authors, 2011-05-21

Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0

From: Changli Gao <hidden>
Date: 2011-03-02 14:37:11
Also in: netfilter-devel

On Wed, Mar 2, 2011 at 7:37 PM, Patrick McHardy [off-list ref] wrote:
Am 23.02.2011 18:07, schrieb "Oleg A. Arkhangelsky":
quoted
Hello,

Got this panic yesterday:
http://www.progtech.ru/~oleg/crash.txt

The offending instruction is:
cmpb 54(%edx), %cl # <variable>.tuple.dst.protonum,

and here is the assembler code of net/ipv4/netfilter/nf_nat_core.c:
http://www.progtech.ru/~oleg/nf_nat_core.s

Quick investigation lead me to conclusion that the problem is in
return of same_src function:

        return (t->dst.protonum == tuple->dst.protonum &&
                t->src.u3.ip == tuple->src.u3.ip &&
                t->src.u.all == tuple->src.u.all);

So either t or tuple pointer is bad, but I don't understand how
this can be.
t should be NULL here, as offsetof(struct nf_conn, dst.protonum) == 0x36.
We should free the nf_ct_extend with call_rcu(), since nat ext is
referenced in the rcu read context.

 717 void nf_conntrack_free(struct nf_conn *ct)
 718 {
 719         struct net *net = nf_ct_net(ct);
 720
 721         nf_ct_ext_destroy(ct);
 722         atomic_dec(&net->ct.count);
 723         nf_ct_ext_free(ct);

if (ct->ext)
   call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);

 724         kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
 725 }
 726 EXPORT_SYMBOL_GPL(nf_conntrack_free);

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help