in pf_state_key_attach(), when we find that there already is a state key that we can attach the state to, make sure to not overwrite the state key pointer in the state that was just set to the existing state key with the state key that was supplied with the state and just free'd (well, pool_put'd). by the time we clean up the state and try to follow it to RB_REMOVE etc we'd follow that garbage pointer to either an unrelated state key or the old state key still sitting unused in the pool. should fix the RB_REMOVE panics some people have been seeing. "clearly ok, please commit" ryan
in pf_state_key_attach(), when we find that there already is a state key
that we can attach the state to, make sure to not overwrite the state key
pointer in the state that was just set to the existing state key with the
state key that was supplied with the state and just free'd (well, pool_put'd).
by the time we clean up the state and try to follow it to RB_REMOVE etc
we'd follow that garbage pointer to either an unrelated state key or the old
state key still sitting unused in the pool.
should fix the RB_REMOVE panics some people have been seeing.
"clearly ok, please commit" ryan

orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars