Date:   Sun, 12 Feb 2023 13:53:20 +0100
From:   Florian Westphal <fw@strlen.de>
To:     Pablo Neira Ayuso <pablo@netfilter.org>
Cc:     Florian Westphal <fw@strlen.de>, Hangyu Hua <hbh25y@gmail.com>,
        kadlec@netfilter.org, davem@davemloft.net, edumazet@google.com,
        kuba@kernel.org, pabeni@redhat.com,
        netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: netfilter: fix possible refcount leak in
 ctnetlink_create_conntrack()
Message-ID: <20230212125320.GA780@breakpoint.cc>
References: <20230210071730.21525-1-hbh25y@gmail.com>
 <20230210103250.GC17303@breakpoint.cc>
 <Y+ZrvJZ2lJPhYFtq@salvia>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y+ZrvJZ2lJPhYFtq@salvia>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > One way would be to return 0 in that case (in
> > nf_conntrack_hash_check_insert()).  What do you think?
> 
> This is misleading to the user that adds an entry via ctnetlink?
> 
> ETIMEDOUT also looks a bit confusing to report to userspace.
> Rewinding: if the intention is to deal with stale conntrack extension,
> for example, helper module has been removed while this entry was
> added. Then, probably call EAGAIN so nfnetlink has a chance to retry
> transparently?

Seems we first need to add a "bool *inserted" so we know when the ct
entry went public.

I'll also have a look at switching to a refcount based model for
all extensions that reference external objects, this would avoid
the entire problem, but thats likely more intrusive.