Re: [PATCH net] netfilter: br_netfilter: reread nf_conn from skb after confirm()

Florian Westphal <[email protected]>
Newsgroups gmane.linux.network.bridge,gmane.comp.security.firewalls.netfilter.devel,gmane.linux.network,gmane.linux.kernel
Message-ID <[email protected]>
Wang Liang <[email protected]> wrote:
> 
> 在 2025/8/20 19:31, Florian Westphal 写道:
> > Wang Liang <[email protected]> wrote:
> > > Previous commit 2d72afb34065 ("netfilter: nf_conntrack: fix crash due to
> > > removal of uninitialised entry") move the IPS_CONFIRMED assignment after
> > > the hash table insertion.
> > How is that related to this change?
> > As you write below, the bug came in with 62e7151ae3eb.
> 
> Before the commit 2d72afb34065, __nf_conntrack_confirm() set
> 'ct->status |= IPS_CONFIRMED;' before check hash, the warning will not
> happen, so I put it here.

Oh, right, the problem was concealed before this.

> > There is a second bug here, confirm can return NF_DROP and
> > nfct will be NULL.
> 
> Thanks for your suggestion!
> 
> Do you mean that ct may be deleted in confirm and return NF_DROP, so we can
> not visit it in br_nf_local_in() and need to add 'case NF_DROP:' here?
>
> I cannot find somewhere set skb->_nfct to NULL and return NF_DROP. Can you
> give some hints?

You are right, skb->_nfct isn't set to NULL in case NF_DROP is returned.
However, the warning will trigger as we did not insert the conntrack
entry in that case.

I suggest to remove the warning, I don't think it buys anything.

Thanks.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.