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