On Wed, Sep 11, 2013 at 05:28:05PM +0200, Michal Kubecek wrote: > > Looking at > > your proposed fix, the NAT extension data should have been cleaned > > from the bysource list in nf_nat_cleanup_conntrack (via __nf_ct_ext_destroy) > > before reaching the kfree. Would you agree? > > It is cleaned from the list but as it is an RCU list, other readers can > still be holding pointers to it. We have to wait for the RCU grace > period before we can reuse it. Agreed - looks like your fix should work. However, two nits: 1) normally RCU functions have _rcu suffixes. So nf_ct_ext_free should become nf_ct_ext_free_rcu. 2) kfree_rcu was not added to the kernel until 3.0. All of the bug reports I've been looking into (including the original in netfilter bugzilla at http://bugzilla.netfilter.org/show_bug.cgi?id=714) have been reported in 2.6.32 or earlier kernels. So a different fix would need to be backported for -stable. For that, we would probably export __nf_ct_ext_free_rcu from nf_conntrack_extend.c and change the kfree call in nf_ct_ext_free_rcu to call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu). Of course the alternative is just to use this fix for both old and new kernels for simplicity. > No, it is a bugreport from our customer. And even that customer > encountered it only once so far. Which is not very surprising as to > reproduce it, you have to be (un)lucky twice: first to have someone > overwrite the area soon enough and second to have someone access the > area after it is overwritten. Yes, hitting this seems dependent upon phase of the moon. Phil -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
