EAP peer: Make EAP-Success handling more robust against race conditions
When ERP initialization was moved from the METHOD state to the SUCCESS
state, the conditions for checking against EAP state being cleared was
missed. The METHOD state verified that sm->m is not NULL while the
SUCCESS state did not have such a check. This opened a window for a race
condition where processing of deauthentication event and EAPOL RX events
could end up delivering an EAP-Success to the EAP peer state machine
after the state had been cleared. This issue has now been worked around
in another manner, but the root cause for this regression should be
fixed as well.
Check that the EAP state machine is properly configured before trying to
initialize ERP in the SUCCESS state.
Fixes: 2a71673e27
("ERP: Derive ERP key only after successful EAP authentication")
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit is contained in:
parent
19a11f629f
commit
c733664be9
1 changed files with 14 additions and 0 deletions
|
@ -1069,6 +1069,20 @@ SM_STATE(EAP, SUCCESS)
|
|||
wpa_msg(sm->msg_ctx, MSG_INFO, WPA_EVENT_EAP_SUCCESS
|
||||
"EAP authentication completed successfully");
|
||||
|
||||
if (!config || !sm->m) {
|
||||
/*
|
||||
* This should not happen under normal conditions, but be more
|
||||
* careful here since there was an earlier case where
|
||||
* EAP-Success could end up getting delivered to the state
|
||||
* machine for processing after the state had been cleaned with
|
||||
* a call to eap_invalidate_cached_session() (and also
|
||||
* eapol_sm_notify_config() having been used to clear EAP
|
||||
* configuration in the EAPOL state machine).
|
||||
*/
|
||||
wpa_printf(MSG_DEBUG,
|
||||
"EAP: State machine not configured - cannot initialize ERP");
|
||||
return;
|
||||
}
|
||||
if (config->erp && sm->m->get_emsk && sm->eapSessionId &&
|
||||
sm->m->isKeyAvailable &&
|
||||
sm->m->isKeyAvailable(sm, sm->eap_method_priv))
|
||||
|
|
Loading…
Reference in a new issue