GitLab

am: f5974f2c

* commit 'f5974f2c':
  WNM: Ignore Key Data in WNM Sleep Mode Response frame if no PMF in use

am: a8da4f66

* commit 'a8da4f66':
  EAP-pwd server: Fix last fragment length validation

am: 3aa9ad54

* commit '3aa9ad54':
  EAP-pwd peer: Fix last fragment length validation

WNM Sleep Mode Response frame is used to update GTK/IGTK only if PMF is
enabled. Verify that PMF is in use before using this field on station
side to avoid accepting unauthenticated key updates.

Bug: 25266660

Change-Id: Ib4b80f9c9e4aa5ea0b827c5202809c9660ad9b39
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

All but the last fragment had their length checked against the remaining
room in the reassembly buffer. This allowed a suitably constructed last
fragment frame to try to add extra data that would go beyond the buffer.
The length validation code in wpabuf_put_data() prevents an actual
buffer write overflow from occurring, but this results in process
termination. (CVE-2015-5314)

Bug: 25510821

Change-Id: I43a9e6270b4ae693fae15314c3ba1f4baef7c083
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

All but the last fragment had their length checked against the remaining
room in the reassembly buffer. This allowed a suitably constructed last
fragment frame to try to add extra data that would go beyond the buffer.
The length validation code in wpabuf_put_data() prevents an actual
buffer write overflow from occurring, but this results in process
termination. (CVE-2015-5315)

Bug: 25510821

Change-Id: Ic509a6efedc3da9ff40f2842fab5547d087f64de
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

* commit 'fdb708a3':
  P2P: Validate SSID element length before copying it

This fixes a possible memcpy overflow for P2P dev->oper_ssid in
p2p_add_device(). The length provided by the peer device (0..255 bytes)
was used without proper bounds checking and that could have resulted in
arbitrary data of up to 223 bytes being written beyond the end of the
dev->oper_ssid[] array (of which about 150 bytes would be beyond the
heap allocation) when processing a corrupted management frame for P2P
peer discovery purposes.

This could result in corrupted state in heap, unexpected program
behavior due to corrupted P2P peer device information, denial of service
due to process crash, exposure of memory contents during GO Negotiation,
and potentially arbitrary code execution.

Thanks to Google security team for reporting this issue and smart
hardware research group of Alibaba security team for discovering it.

Change-Id: I9f350f20cdd010f2c096514b245b4a901ad74e46
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>

* commit 'dd9a784a':

* commit '243e04f8':
  Treat VER_2_1_DEVEL the same as VER_0_8_X
  Android: Do not compile wpa_supplicant if not chosen

The Android.mks to include are actually the same.

Change-Id: I0ca51e744c9f1f09812f20064c0ae316856e0dc4

Change-Id: I60c91fd04589386f9a7cbf1ae82fd545634640c7
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

Bug: 11631777

Change-Id: I3fbcf3cef4a6a4d894f78dd3dbe4757831e4fc56
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

Change-Id: I58bc138d5b74b1b62f7a9612c12399083aef1374
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

DISCONNECT followed by ENABLE_NETWORK ended up starting a scan for a new
connection due to wpa_supplicant_enable_one_network() setting
wpa_s->reassociate = 1. This was done regardless of wpa_s->disconnected
being 1 which should imply that wpa_supplicant should not try to connect
before asked explicitly with REASSOCIATE or RECONNECT.

Fix this by making ENABLE_NETWORK setting of reassociate = 1 and
starting of scans for connection conditional on wpa_s->disconnected ==
0. This will make ENABLE_NETWORK trigger a connection only if
wpa_supplicant is already in a state where it would try to connect if
there are any enabled networks.

Bug: 10483405

Change-Id: Iae606745270f6f3185d5705947f8ccd46bc3a904
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

Bug: 11105901

Change-Id: Ibe8e85f47e95177700deedccb408f1eec85b8f3d
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

A new TDLS request shall transmit TPK M1 frame with a unique INonce.
Thus a new explicit request would fail an ongoing TDLS negotiation with
the error "TDLS: FTIE SNonce in TPK M3 does not match with FTIE SNonce
used in TPK M1" if the peer happens to receive two M1 frames before an
M3 frame. Check for the ongoing negotiation with the peer and do not
start a new one if we are already in a setup negotiation with the peer.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

This function is used only with external setup, so this can cleaned up
to use simpler design.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

There is no need to go through the peer list when we already have a
pointer to the specific peer entry.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

This is called from number of locations and it is more efficient to use
a new helper function instead of wpa_tdls_disable_link() that would do
peer address search from the list of peers.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

Making this function be used only for external setup case simplifies the
implementation and makes core wpa_supplicant calls in ctrl_iface.c and
events.c consistent.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

There is no point in updating the RNonce for every obtained TPK M1 frame
(e.g., retransmission due to timeout) with the same INonce (SNonce in
FTIE). Update RNonce only if a TPK M1 is received with a different
INonce (new TDLS session) to avoid issues with two setup exchanges
getting mixed and exchange failing due to mismatching nonces ("TDLS:
FTIE ANonce in TPK M3 does not match with FTIE ANonce used in TPK M2").

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

Clear the peer information and disable the created link on a
failed TDLS setup negotiation. This is needed to avoid leaving
TDLS setup pending and to return to the AP path in case anything
goes wrong during the setup attempt.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

If there are large number of BSSes in the scan results, BSS table update
could have added a BSS entry to the last_scan_res in a case where that
BSS entry got just deleted. This would happen only if there are more
than bss_max_count (by default 200) BSSes and if at least bss_max_count
of those BSSes are known (match a configured network). In such a case,
wpa_bss_add() could end up allocating a new BSS entry and return a
pointer to that entry even if it was the one that ended up getting freed
to keep the BSS table length within the limit. This could result in
freed memory being used and the process crashing (likely with segfault)
when trying to access information from that BSS entry.

Fix the issue by removing the oldest BSS entry before linking the new
entry to the table. This makes sure the newly added entry will never get
picked up as the one to be deleted immediately.

Bug: 10964663

Change-Id: I495dd2503127263746a69c9ef040c9e62fec0bda
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

When no other user preference is specified, opt to use an operating
channel that allows 5 GHz band to be used rather than 2.4 GHz.
Previously, this was already done in practice for HT40 channels since no
such channel is enabled for P2P on 2.4 GHz. This commit extends this to
apply 5 GHz preference for 20 MHz channels as well.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>

Bug: 10641114

Change-Id: I621ef6d5e45392d86211bc3936e85b876b96aec4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

Conflicts:
	src/p2p/p2p_utils.c

Bug: 10641114

Change-Id: I621ef6d5e45392d86211bc3936e85b876b96aec4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>