Fix EAPOL-Key msg 1/4 processing in a corner case
If reassoc_same_bss_optim=1 is used to optimize reassociation back to the same BSS, it was possible for sm->pmk_len to be 0 due to a disconnection event getting processed after sending out the reassociation request. This resulted in wpa_sm_rx_eapol() calling wpa_mic_len() with incorrect PMK length when PMKSA caching was being attempted. That resulted in incorrect mic_len getting determined and not finding the correct Key Data Length field value. This could result in failing to complete 4-way handshake successfully. Fix this by updating the current PMK length based on the selected PMKSA cache entry if sm->pmk_len is not set when processing EAPOL-Key msg 1/4. Signed-off-by: Jouni Malinen <j@w1.fi>
This commit is contained in:
parent
96e63008fb
commit
8aa91282a1
1 changed files with 5 additions and 2 deletions
|
@ -2451,13 +2451,16 @@ int wpa_sm_rx_eapol(struct wpa_sm *sm, const u8 *src_addr,
|
|||
u8 *tmp = NULL;
|
||||
int ret = -1;
|
||||
u8 *mic, *key_data;
|
||||
size_t mic_len, keyhdrlen;
|
||||
size_t mic_len, keyhdrlen, pmk_len;
|
||||
|
||||
#ifdef CONFIG_IEEE80211R
|
||||
sm->ft_completed = 0;
|
||||
#endif /* CONFIG_IEEE80211R */
|
||||
|
||||
mic_len = wpa_mic_len(sm->key_mgmt, sm->pmk_len);
|
||||
pmk_len = sm->pmk_len;
|
||||
if (!pmk_len && sm->cur_pmksa)
|
||||
pmk_len = sm->cur_pmksa->pmk_len;
|
||||
mic_len = wpa_mic_len(sm->key_mgmt, pmk_len);
|
||||
keyhdrlen = sizeof(*key) + mic_len + 2;
|
||||
|
||||
if (len < sizeof(*hdr) + keyhdrlen) {
|
||||
|
|
Loading…
Reference in a new issue