GitLab

am: 5060e1c0

* commit '5060e1c0':
  EAP-pwd peer: Fix last fragment length validation

am: bc454293

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

am: 9c5ac8d9

* commit '9c5ac8d9':
  EAP-pwd peer: Fix last fragment length validation

am: 3aa9ad54

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

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 '2a856dee':
  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.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>

(cherry picked from commit fdb708a3)

Change-Id: Ibc53ff533f78cfcd7c51fbb5d5494b828f184cc8

am 56509450: am dc5da6ac: am b73408d1: am fdb708a3: P2P: Validate SSID element length before copying it

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

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

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

* 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>

wpa_ctrl.c gets sys/stat.h inherited from
private/android_filesystem_config.h it should
not rely on this in the future. The intent is
to move fs_config function into libcutils and
thus deprecate any need for sys/stat.h in this
include file.

Bug: 19908228
Change-Id: I83a682a0bebd3e1a50cf4a6e42fa37b194a95bc0

* commit '0a217de1':
  Don't write to wpa_supplicant.conf directly

There is a chance that wpa_supplicant may get killed during
the time it is writing config file. If this happens, user
information like SSIDs and passwords can be lost forever.

This change works around that by writing config to a
temporary file and then renaming the file to the correct name.

Bug: 19224089

Change-Id: I1709cdd5e5c6dfa3073e42c644fae941b43401cc
Signed-off-by: Vinit Deshpande <vinitd@google.com>

* commit '6157d599':
  Android: Remove superfluous OpenSSL include paths.

The libcrypto and libssl modules (and their respective static and host
versions) use LOCAL_EXPORT_C_INCLUDE_DIRS thus just including the module
is sufficient.

Change-Id: If8722a70dd82aad34d4a203c2af46110c98f42dc

* commit '59c61501':
  Remove hardcoded ICU include paths.

ICU exports them using LOCAL_EXPORT_C_INCLUDE_DIRS.

bug: 18581021
Change-Id: I0a971ec93c529b9adb4056ba048eab09d96b6ff5

* commit 'adaa28a8':
  Return only full network line in list_networks

* commit '68c7ea4c':
  List all networks despite message limit of 4096 bytes

* commit 'a7c60b4c':
  nl80211: Ignore Connect failure for the previous association

Suppose there are two APs (AP1 & AP2) and user attempted to connect to
AP2 before the previous connection with AP1 could succeed. Now, if the
connection event comes for the older AP with failed status, we should
just ignore it as the wpa_supplicant state has moved to "ASSOCIATING"
with the new AP (AP2).

This is a similar to the case where a disconnection event is ignored for
a case where local disconnect request can cause the extra event to show
up during the next association process following that command.
Signed-off-by: Jithu Jance <jithu@broadcom.com>
Signed-off-by: vandwalle <vandwalle@google.com>

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

This change creates 'LIST_NETWORK LAST_ID=x' form to allow
retrieval of all networks saved in the system. Without this form,
only first few (whatever fills in first 4096 bytes) can be
retrieved.
Signed-off-by: Vinit Deshpande <vinitd@google.com>

* commit 'fee0f928':
  Work around AP misbehavior on EAPOL-Key descriptor version

* commit '658fb4ad':
  Work around AP misbehavior on EAPOL-Key descriptor version

It looks like some APs are incorrectly selecting descriptor version 3
(AES-128-CMAC) for EAPOL-Key frames when version 2 (HMAC-SHA1) was
expected to be used. This is likely triggered by an attempt to negotiate
PMF with SHA1-based AKM.

Since AES-128-CMAC is considered stronger than HMAC-SHA1, allow the
incorrect, but stronger, option to be used in these cases to avoid
interoperability issues with deployed APs.

This issue shows up with "WPA: CCMP is used, but EAPOL-Key descriptor
version (3) is not 2" in debug log. With the new workaround, this issue
is ignored and "WPA: Interoperability workaround: allow incorrect
(should have been HMAC-SHA1), but stronger (is AES-128-CMAC), descriptor
version to be used" is written to the log.

Bug: 18411110

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

* commit '2e425d69':
  Cumulative patch from commits: a7f5271 and 7465640

a7f5271 Update pending connect radio work BSS pointer on scan update
7465640 Invoke connect work done for all the connection failure cases

Bug: 18312770

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

* commit '907fe1cb':

* commit 'a3015e7a':

* commit '429a33ca':

* commit 'a7b06faf':
  Cumulative patch to Release 2.3