When sub_pres_vlr_fsm_start() is called, it dispatches an event which may in
some cases already cause tear down and free of the parent FSM instance, after
which storing the returned instance pointer in that parent's metadata will use
freed memory. Instead, pass the target pointer to remember the instance at to
sub_pres_vlr_fsm_start() and assign the pointer *before* firing the event.
Explain so in a new comment.
I haven't checked whether that pointer is actually used at all -- this is the
easiest way to fix the use-after-free without getting sucked into semantic
questions.
Change-Id: Ibdc0b64cd12ba3e2b9737e3517d8484e67abcf04
The name auth_tuple_max_use_count suggests that if I want to use each auth
tuple exactly once, I need to set it to 1. Curiously, so far you need to set
to intended uses - 1.
Reflect this in its name by renaming to auth_tuple_max_reuse_count.
I first considered to not rename but change the if-conditions so that == 1
means each tuple is used once, and upon struct vlr allocation, set the default
to 1. That would also logically entail that setting to 0 means to re-use
vectors infinitely often, like now a value < 0 does. That means, when
allocating a vlr struct zeroed out, we would by default have the most
dangerous/unsafe configuration. It's no problem to set a default to 1 upon
allocation, but by renaming the variable instead, we get safer alloc-zero
behavior and don't need to change any conditionals in the code (even though the
patch ends up considerably larger from all the renaming).
Change-Id: I0b036cae1536d5d6fb2304f837ed1a6c3713be55
Neels Hofmeyr