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:
Jouni Malinen 2020-08-22 14:00:34 +03:00
parent 96e63008fb
commit 8aa91282a1

View file

@ -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) {