mirror of
https://github.com/vanhoefm/fragattacks.git
synced 2025-01-20 03:44:02 -05:00
cc79eb725f
int_array_concat() and int_array_add_unique() could potentially end up overflowing the int type variable used to calculate their length. While this is mostly theoretical for platforms that use 32-bit int, there might be cases where a 16-bit int overflow could be hit. This could result in accessing memory outside buffer bounds and potentially a double free when realloc() ends up freeing the buffer. All current uses of int_array_add_unique() and most uses of int_array_concat() are currently limited by the buffer limits for the local configuration parameter or frame length and as such, cannot hit this overflow cases. The only case where a long enough int_array could be generated is the combination of scan_freq values for a scan. The memory and CPU resource needs for generating an int_array with 2^31 entries would not be realistic to hit in practice, but a device using LP32 data model with 16-bit int could hit this case. It is better to have more robust checks even if this could not be reached in practice, so handle cases where more than INT_MAX entries would be added to an int_array as memory allocation failures instead of allowing the overflow case to proceed. Signed-off-by: Jouni Malinen <j@w1.fi> |
||
|---|---|---|
| .. | ||
| ap | ||
| common | ||
| crypto | ||
| drivers | ||
| eap_common | ||
| eap_peer | ||
| eap_server | ||
| eapol_auth | ||
| eapol_supp | ||
| fst | ||
| l2_packet | ||
| p2p | ||
| pae | ||
| radius | ||
| rsn_supp | ||
| tls | ||
| utils | ||
| wps | ||
| lib.rules | ||
| Makefile | ||