diff options
author | 2003-06-27 11:38:23 +0000 | |
---|---|---|
committer | 2003-06-27 11:38:23 +0000 | |
commit | 3670ecce04673ec40a1912dfe7d3590260e58a5c (patch) | |
tree | 3b735676b0b1d8e1166f6039ae3fc70b5873b309 /usr.bin/diff/diff.c | |
parent | no more kerberos IV, PR3335 (diff) | |
download | wireguard-openbsd-3670ecce04673ec40a1912dfe7d3590260e58a5c.tar.xz wireguard-openbsd-3670ecce04673ec40a1912dfe7d3590260e58a5c.zip |
move down pf_tag_unref() calls in pf_rm_rule() to after the check wetehr there
are still states for the given rule existant.
based on a very nice analysis from cedric@, that is so completely right that
I have nothing to add:
in pf_rm_rule(), the pf_tag_unref() calls are done *before*
the if (rule->states > 0 || rule->entries.tqe_prev != NULL) test.
That mean that the two pf_tag_unref() calls could occur *twice*
for a given rule: first when the rule is removed from the ruleset
and (if the rule was kept around because of a state) a second
time when the state refcount drops to zero and the rule gets
really deleted. Unless I'm mistaken, that breaks the refcounting.
...and cedric was not mistaken.
and, as daniel pointed out:
The breakage this causes is so subtle, I doubt anyone noticed it before, if it
did occur.
consensus on this between cedric, dhartmei and myself
Diffstat (limited to 'usr.bin/diff/diff.c')
0 files changed, 0 insertions, 0 deletions