Re: [PATCH nf-next] netfilter: conntrack: check NULL when calling nf_ct_ext_find()

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> nf_ct_ext_find() might return NULL since ct extensions may be declared
> stale because of object dependencies or modules that are going away.
> 
> When helper is removed, nf_ct_iterate_destroy() unhelps the conntrack
> entries. Then, the nf_ct_ext_find() might return NULL if the extension
> is stale for unconfirmed conntracks if the genid validation fails.
> 
> Add the null check to:
> 
> - nfct_help()
> - nfct_help_data()
> - nfct_seqadj()
> 
> that call this function since packet path could be walking over helper
> while it is being removed.
> 
> While at it, fetch ct helper area in nf_ct_expect_related_report() only
> once and pass it on to other ancilliary functions. Replace WARN_ON()
> by WARN_ON_ONCE() in nf_ct_unlink_expect_report().
> 
> Fixes: c56716c69ce1 ("netfilter: extensions: introduce extension genid count")

I'm not sure this tag is correct.

The genid checks are only for unconfirmed entries, not in hash.

nfct_help() and nfct_help_data() can return NULL as you say, but
I don't see how this relates to the above commit either.

That said, I agree with the patch.