Re: [PATCH ipsec-next 01/10] xfrm: state: fix sparse warnings on xfrm_state_hold_rcu

[Leon Romanovsky <leon@kernel.org>]

On Tue, Mar 10, 2026 at 08:49:44PM +0100, Florian Westphal wrote:
> Leon Romanovsky <leon@kernel.org> wrote:
> > > You can only use xfrm_state_hold() if the refcount is already > 0.
> > > xfrm_state_hold uses refcount_inc(), so you get a UaF warn splat
> > > if this assuption doesn't hold true.
> > 
> > I know it, the thing that bothers me is that it is unclear how
> > xfrm_state_hold_rcu() can have refcount equal to 0.
> > 
> > xfrm_state_put() decreases refcount and when it is zero, it calls
> > to __xfrm_state_destroy(). The latter assumes that the state was
> > already removed from various hlists.
> 
> Yes, insertion in the table means refcount is 1, but userspace
> can zap states at any time, e.g.:
> 
> xfrm_del_sa -> xfrm_state_delete -> __xfrm_state_delete (which
> unlinks from hash lists).
> 
> The last xfrm_state_put() in that function may cause 1 -> 0
> transition.  Parallel lookup can still observe that state,
> so it has to pretend it wasn't there to begin with.

Yes, this is possible scenario and this is what is worth to document.

Thanks