Re: pf: use-after-free and table leak in pf_sourcelim_add()

Hello,

On Fri, Apr 10, 2026 at 10:41:56AM +0200, Renaud Allard wrote:
> On Thu, Apr 10, 2026, Alexandr Nedvedicky wrote:
> > I think this needs to be moved to the free: goto target below.
> 
> The early goto free paths (strlcpy failures) never attach a
> table, so the != NULL guard works at either location.
> 
> At free: the PF_LOCK is no longer held.  pfr_detach_table does
> a non-atomic refcount decrement, and all existing callers appear
> to hold PF_LOCK (pf_free_state via pf_rm_rule, pf_commit_rules,
> pf_sourcelim_rollback, etc.).  Since pfr_ktable objects are
> shared globally, pf_free_state from the packet path could race
> on the same refcount.
> 
> At unlock: the lock is still held, no race possible.
> But you know the locking better than me and maybe I missed
> something about the locking.
> 
> Updated diff moves it to free: as you suggested.

    sorry, you are absolutely right about locking. your first
    version of the diff is correct. 

thanks and
regards
sashan