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

From: Florian Westphal <[email-masked]>
Date: Tue, 10 Mar 2026 20:49:44 +0100

Leon Romanovsky <[email-masked]> 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.