The ieee80211_key struct can be kfree()d several times in the function, for
example if some of the key setup functions fails beforehand, but there's no
check if the struct is still valid before we call memcpy() and INIT_LIST_HEAD()
on it. In some cases (like it was in my case), if there's missing aes-generic
module it could lead to the following kernel OOPS:
Unable to handle kernel NULL pointer dereference at virtual address
0000018c
....
PC is at memcpy+0x80/0x29c
...
Backtrace:
[<
bf11c5e4>] (ieee80211_key_alloc+0x0/0x234 [mac80211]) from [<
bf1148b4>] (ieee80211_add_key+0x70/0x12c [mac80211])
[<
bf114844>] (ieee80211_add_key+0x0/0x12c [mac80211]) from [<
bf070cc0>] (__cfg80211_set_encryption+0x2a8/0x464 [cfg80211])
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
if (IS_ERR(key->u.ccmp.tfm)) {
err = PTR_ERR(key->u.ccmp.tfm);
kfree(key);
- key = ERR_PTR(err);
+ return ERR_PTR(err);
}
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
if (IS_ERR(key->u.aes_cmac.tfm)) {
err = PTR_ERR(key->u.aes_cmac.tfm);
kfree(key);
- key = ERR_PTR(err);
+ return ERR_PTR(err);
}
break;
}