[bug report] Potential order bug in 'net/xfrm/xfrm_state.c', primarily in 'xfrm_state_walk_done()'

[Ginger]

Dear Linux kernel maintainers,

My research-based static analyzer found a potential orderbug within
the 'net/xfrm' subsystem, more specifically, in
'net/xfrm/xfrm_state.c'.

Kernel version: long-term kernel v6.18.9

Potential concurrent triggering executions:
T0:
xfrm_state_walk_done
    --> kfree(walk->filter); [t0]
    --> list_del(&walk->all); [t3]

T1:
xfrm_state_walk
   --> list_for_each_entry_from(x, &net->xfrm.state_all, all) [t1]
   --> __xfrm_state_filter_match(state, walk->filter) [t2]

In T0, 'walk->filter' is free before the parent 'walk' gets removed
from the global list. Thus, it is possible for T1 to still get the
same 'walk' by iterating through the list linked via 'walk->all' and
access the 'filter' field, which has already been freed.
The concurrent buggy order is t0 -> t1 -> t2 -> t3.

Thank you for your time and consideration.

Sincerely,
Ginger