Re: pf: u_int32_t conn counter underflow in pf_src_tree_remove_state()

Dear Janak,

thank you for detailed report with pointers to the pf(4) code.
I've read your report and understand the source node connection counter
underflow issue (sn->conn underflow).

On Thu, Aug 06, 2026 at 11:31:34AM +0200, Janak Trivedi wrote:
</snip>
> 
> Option 1 ??? Minimal fix (add zero check):
> 
>   /* CURRENT (buggy): */
>   if (st->src.tcp_est)
>       --sni->sn->conn;
> 
>   /* FIXED (safe): */
>   if (st->src.tcp_est && sni->sn->conn > 0)
>       --sni->sn->conn;
> 
>   Pros: Simple one-line change
>         Prevents underflow completely
>         Minimal risk of regression
>   Cons: conn may slightly overcount during high-rate
>         FIN_WAIT accumulation (benign)

    I suspect the problem might be coming from non-atomic
    manipulation of sn->conn counter.

    The thing is the counter gets incremented on SYN_SENT -> ESTABLISHED
    state transition. For that kind of transition the state exists already.
    that means pf(4) runs with reader lock on state and source node table.
    pf(4) might be simultaneously handling two packets which belong to two
    different states but share the same source node entry. There are like two
    threads doing sn->conn++; on the same `sn` instance.  and just one counter
    bump is observed.

I will try to reproduce the issue and verify my suspicion. Give me just
two or three days to come back here.

BTW: what hardware your router is using? is it amd64? or something else?

thanks and
regards
sashan