]> git.ipfire.org Git - thirdparty/hostap.git/commit
P2P: Fix a possible buffer overflow in struct p2p_reg_class
authorVamsi Krishna <vamsin@codeaurora.org>
Wed, 12 Feb 2020 09:44:59 +0000 (15:14 +0530)
committerJouni Malinen <jouni@codeaurora.org>
Wed, 12 Feb 2020 21:17:24 +0000 (23:17 +0200)
commit75d0ec47021c893eeecf1c19d06e6a5620565433
treeee69767cf558be110b2d8d72f5372f43c3d66102
parent5551317834979458ad78ff06676a357562b0ea06
P2P: Fix a possible buffer overflow in struct p2p_reg_class

Avoid adding more than P2P_MAX_REG_CLASSES operating classes or
P2P_MAX_REG_CLASS_CHANNELS channels while populating P2P channels. The
current limits on the operating classes or channels per operating class
could be hit in some case (mainly, with 6 GHz, but in theory, with a
2.4/5/60 GHz capable device as well).

If the local driver advertised a larger number of supported operarting
classes or channels per operating class, the construction of the struct
p2p_reg_class instances could have resulted in writing beyond the end of
the buffer and ending up corrupting memory around the struct p2p_config.
This could result in unexpected behavior in some other operations that
used corrupted memory, e.g., generation of a P2P Channel List failing
(with validation code stopping the process to avoid writing beyond the
end of the message buffer) due to not having sufficient buffer space for
the corrupted data.

This issue is triggered only based on information from the local driver
(mainly based on addition of support for 6 GHz band operating classes),
so the issue cannot be triggered based on received frames or any other
remote information.

The issue was introduced by commit d7c2c5c98c4f ("AP: Add initial
support for 6 GHz band") which added the operating class 131 which has
sufficiently large number of channels to go beyond the
P2P_MAX_REG_CLASS_CHANNELS limit.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wpa_supplicant/p2p_supplicant.c