Hello,
On Thu, Aug 06, 2026 at 12:03:54PM +0100, Stuart Henderson wrote:
</snip>
> >
> > Current code in pf_src_tree_remove_state():
> >
> > ?? pf_src_tree_remove_state(struct pf_state *st)
> > ?? {
> > ?? ?? ?? u_int32_t ?? ?? ?? ?? timeout;
> > ?? ?? ?? struct pf_sn_item *sni;
> >
> > ?? ?? ?? while ((sni = SLIST_FIRST(&st->src_nodes)) != NULL) {
> > ?? ?? ?? ?? ?? SLIST_REMOVE_HEAD(&st->src_nodes, next);
> >
> > ?? ?? ?? ?? ?? if (st->src.tcp_est)
> > ?? ?? ?? ?? ?? ?? ?? --sni->sn->conn; ?? ?? ?? ??/* BUG: no zero check,
> > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??tcp_est never
> > cleared
> > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??on FIN_WAIT
> > transition */
>
> Surely the bug is that tcp_est isn't cleared, wouldn't this zero
> check just be hiding the problem?
>
>
this is something I'd like to take a closer look. my current
understanding is that when pf(4) is running in this code area
the state flag `tcp_set` should not matter much. The state is
being removed and call to pf_src_tree_remove_state()/pf_remove_sate()
happens exactly once for each state (!I think!). So the setting
the flag to zero after in pf_src_tree_remove_state() should not matter
much because pf(4) never reaches that place more than one time
for particular state. that's my current understanding, but I need
to close look.
thanks and
regards
sashan
