Your message dated Sat, 17 Sep 2016 13:08:06 +0100
with message-id <1474114086.2011.126.ca...@adam-barratt.org.uk>
and subject line Closing p-u bugs for updates in 8.6
has caused the Debian Bug report #832004,
regarding jessie-pu: package wpa/2.3-1+deb8u4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
832004: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian....@packages.debian.org
Usertags: pu

Hi,

I have prepared an upload fixing CVE-2016-4476 and CVE-2016-4477.
Please find the attached debdiff.

S├ębastien Delafond advised me this upload is for the point release,
and isn't supposed to be handled by the Security Team.

-- 
Cheers,
  Andrew
diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog
--- wpa-2.3/debian/changelog	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/changelog	2016-07-21 09:19:43.000000000 +0200
@@ -1,3 +1,17 @@
+wpa (2.3-1+deb8u4) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches to address CVE-2016-4476 and CVE-2016-4477, thanks to
+    Salvatore Bonaccorso <car...@debian.org> (Closes: #823411):
+    - WPS: Reject a Credential with invalid passphrase
+    - Reject psk parameter set with invalid passphrase character
+    - Remove newlines from wpa_supplicant config network output
+    - Reject SET_CRED commands with newline characters in the string values
+    - Reject SET commands with newline characters in the string values
+  * Refresh patches to apply cleanly.
+
+ -- Andrew Shadura <andre...@debian.org>  Thu, 21 Jul 2016 09:19:42 +0200
+
 wpa (2.3-1+deb8u3) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch
--- wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-01/0001-P2P-Validate-SSID-element-length-before-copying-it-C.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,37 @@
+From 9ed4eee345f85e3025c33c6e20aa25696e341ccd Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Tue, 7 Apr 2015 11:32:11 +0300
+Subject: [PATCH] P2P: Validate SSID element length before copying it
+ (CVE-2015-1863)
+
+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 <jo...@qca.qualcomm.com>
+---
+ src/p2p/p2p.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/src/p2p/p2p.c
++++ b/src/p2p/p2p.c
+@@ -736,6 +736,7 @@ int p2p_add_device(struct p2p_data *p2p,
+ 	if (os_memcmp(addr, p2p_dev_addr, ETH_ALEN) != 0)
+ 		os_memcpy(dev->interface_addr, addr, ETH_ALEN);
+ 	if (msg.ssid &&
++	    msg.ssid[1] <= sizeof(dev->oper_ssid) &&
+ 	    (msg.ssid[1] != P2P_WILDCARD_SSID_LEN ||
+ 	     os_memcmp(msg.ssid + 2, P2P_WILDCARD_SSID, P2P_WILDCARD_SSID_LEN)
+ 	     != 0)) {
diff -Nru wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt
--- wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-01/wpa_supplicant-p2p-ssid-overflow.txt	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,68 @@
+wpa_supplicant P2P SSID processing vulnerability
+
+Published: April 22, 2015
+Identifier: CVE-2015-1863
+Latest version available from: http://w1.fi/security/2015-1/
+
+
+Vulnerability
+
+A vulnerability was found in how wpa_supplicant uses SSID information
+parsed from management frames that create or update P2P peer entries
+(e.g., Probe Response frame or number of P2P Public Action frames). SSID
+field has valid length range of 0-32 octets. However, it is transmitted
+in an element that has a 8-bit length field and potential maximum
+payload length of 255 octets. wpa_supplicant was not sufficiently
+verifying the payload length on one of the code paths using the SSID
+received from a peer device.
+
+This can result in copying arbitrary data from an attacker to a fixed
+length buffer of 32 bytes (i.e., a possible overflow of up to 223
+bytes). The SSID buffer is within struct p2p_device that is allocated
+from heap. The overflow can override couple of variables in the struct,
+including a pointer that gets freed. In addition about 150 bytes (the
+exact length depending on architecture) can be written beyond the end of
+the heap allocation.
+
+This could result in corrupted state in heap, unexpected program
+behavior due to corrupted P2P peer device information, denial of service
+due to wpa_supplicant process crash, exposure of memory contents during
+GO Negotiation, and potentially arbitrary code execution.
+
+Vulnerable versions/configurations
+
+wpa_supplicant v1.0-v2.4 with CONFIG_P2P build option enabled
+
+Attacker (or a system controlled by the attacker) needs to be within
+radio range of the vulnerable system to send a suitably constructed
+management frame that triggers a P2P peer device information to be
+created or updated.
+
+The vulnerability is easiest to exploit while the device has started an
+active P2P operation (e.g., has ongoing P2P_FIND or P2P_LISTEN control
+interface command in progress). However, it may be possible, though
+significantly more difficult, to trigger this even without any active
+P2P operation in progress.
+
+
+Acknowledgments
+
+Thanks to Google security team for reporting this issue and smart
+hardware research group of Alibaba security team for discovering it.
+
+
+Possible mitigation steps
+
+- Merge the following commits to wpa_supplicant and rebuild it:
+
+  P2P: Validate SSID element length before copying it (CVE-2015-1863)
+
+  This patch is available from http://w1.fi/security/2015-1/
+
+- Update to wpa_supplicant v2.5 or newer, once available
+
+- Disable P2P (control interface command "P2P_SET disabled 1" or
+  "p2p_disabled=1" in (each, if multiple interfaces used) wpa_supplicant
+  configuration file)
+
+- Disable P2P from the build (remove CONFIG_P2P=y)
diff -Nru wpa-2.3/debian/patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch wpa-2.3/debian/patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch
--- wpa-2.3/debian/patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-02/0001-WPS-Fix-HTTP-chunked-transfer-encoding-parser.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,44 @@
+From 5acd23f4581da58683f3cf5e36cb71bbe4070bd7 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Tue, 28 Apr 2015 17:08:33 +0300
+Subject: [PATCH] WPS: Fix HTTP chunked transfer encoding parser
+
+strtoul() return value may end up overflowing the int h->chunk_size and
+resulting in a negative value to be stored as the chunk_size. This could
+result in the following memcpy operation using a very large length
+argument which would result in a buffer overflow and segmentation fault.
+
+This could have been used to cause a denial service by any device that
+has been authorized for network access (either wireless or wired). This
+would affect both the WPS UPnP functionality in a WPS AP (hostapd with
+upnp_iface parameter set in the configuration) and WPS ER
+(wpa_supplicant with WPS_ER_START control interface command used).
+
+Validate the parsed chunk length value to avoid this. In addition to
+rejecting negative values, we can also reject chunk size that would be
+larger than the maximum configured body length.
+
+Thanks to Kostya Kortchinsky of Google security team for discovering and
+reporting this issue.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/wps/httpread.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/src/wps/httpread.c
++++ b/src/wps/httpread.c
+@@ -533,6 +533,13 @@ static void httpread_read_handler(int sd
+ 					if (!isxdigit(*cbp))
+ 						goto bad;
+ 					h->chunk_size = strtoul(cbp, NULL, 16);
++					if (h->chunk_size < 0 ||
++					    h->chunk_size > h->max_bytes) {
++						wpa_printf(MSG_DEBUG,
++							   "httpread: Invalid chunk size %d",
++							   h->chunk_size);
++						goto bad;
++					}
+ 					/* throw away chunk header
+ 					 * so we have only real data
+ 					 */
diff -Nru wpa-2.3/debian/patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt wpa-2.3/debian/patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt
--- wpa-2.3/debian/patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-02/wps-upnp-http-chunked-transfer-encoding.txt	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,73 @@
+WPS UPnP vulnerability with HTTP chunked transfer encoding
+
+Published: May 4, 2015
+Latest version available from: http://w1.fi/security/2015-2/
+
+
+Vulnerability
+
+A vulnerability was found in the WPS UPnP function shared by hostapd
+(WPS AP) and wpa_supplicant (WPS external registrar). The HTTP
+implementation used for the UPnP operations uses a signed integer for
+storing the length of a HTTP chunk when the chunked transfer encoding
+and may end up using a negative value when the chunk length is indicated
+as 0x8000000 or longer. The length validation steps do not handle the
+negative value properly and may end up accepting the length and passing
+a negative value to the memcpy when copying the received data from a
+stack buffer to a heap buffer allocated for the full request. This
+results in stack buffer read overflow and heap buffer write overflow.
+
+Taken into account both hostapd and wpa_supplicant use only a single
+thread, the memcpy call with a negative length value results in heap
+corruption, but due to the negative parameter being interpreted as a
+huge positive integer, process execution terminates in practice before
+being able to run any following operations with the corrupted heap. This
+may allow a possible denial of service attack through
+hostapd/wpa_supplicant process termination under certain conditions.
+
+WPS UPnP operations are performed over a trusted IP network connection,
+i.e., an attack against this vulnerability requires the attacker to have
+access to the IP network. In addition, this requires the WPS UPnP
+functionality to be enabled at runtime. For WPS AP (hostapd) with a
+wired network connectivity, this is commonly enabled. For WPS station
+(wpa_supplicant) WPS UPnP functionality is used only when WPS ER
+functionality has been enabled at runtime (WPS_ER_START command issued
+over the control interface). The vulnerable functionality is not
+reachable without that command having been issued.
+
+
+Vulnerable versions/configurations
+
+hostapd v0.7.0-v2.4 with CONFIG_WPS_UPNP=y in the build configuration
+(hostapd/.config) and upnp_iface parameter included in the runtime
+configuration.
+
+wpa_supplicant v0.7.0-v2.4 with CONFIG_WPS_ER=y in the build
+configuration (wpa_supplicant/.config) and WPS ER functionality enabled
+at runtime with WPS_ER_START control interface command.
+
+
+Acknowledgments
+
+Thanks to Kostya Kortchinsky of Google Security Team for discovering and
+reporting this issue.
+
+
+Possible mitigation steps
+
+- Merge the following commit and rebuild hostapd/wpa_supplicant:
+
+  WPS: Fix HTTP chunked transfer encoding parser
+
+  This patch is available from http://w1.fi/security/2015-2/
+
+- Update to hostapd/wpa_supplicant v2.5 or newer, once available
+
+- Disable WPS UPnP in hostapd runtime configuration (remove the
+  upnp_iface parameter from the configuration file)
+
+- Do not enable WPS ER at runtime in wpa_supplicant (WPS_ER_START
+  control interface command)
+
+- Disable WPS UPnP/ER from the build (remove CONFIG_WPS_UPNP=y from
+  hostapd/.config and CONFIG_WPS_ER=y from wpa_supplicant/.config)
diff -Nru wpa-2.3/debian/patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch wpa-2.3/debian/patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch
--- wpa-2.3/debian/patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-03/0001-AP-WMM-Fix-integer-underflow-in-WMM-Action-frame-par.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,36 @@
+From ef566a4d4f74022e1fdb0a2addfe81e6de9f4aae Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Wed, 29 Apr 2015 02:21:53 +0300
+Subject: [PATCH] AP WMM: Fix integer underflow in WMM Action frame parser
+
+The length of the WMM Action frame was not properly validated and the
+length of the information elements (int left) could end up being
+negative. This would result in reading significantly past the stack
+buffer while parsing the IEs in ieee802_11_parse_elems() and while doing
+so, resulting in segmentation fault.
+
+This can result in an invalid frame being used for a denial of service
+attack (hostapd process killed) against an AP with a driver that uses
+hostapd for management frame processing (e.g., all mac80211-based
+drivers).
+
+Thanks to Kostya Kortchinsky of Google security team for discovering and
+reporting this issue.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/ap/wmm.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/src/ap/wmm.c
++++ b/src/ap/wmm.c
+@@ -274,6 +274,9 @@ void hostapd_wmm_action(struct hostapd_d
+ 		return;
+ 	}
+ 
++	if (left < 0)
++		return; /* not a valid WMM Action frame */
++
+ 	/* extract the tspec info element */
+ 	if (ieee802_11_parse_elems(pos, left, &elems, 1) == ParseFailed) {
+ 		hostapd_logger(hapd, mgmt->sa, HOSTAPD_MODULE_IEEE80211,
diff -Nru wpa-2.3/debian/patches/2015-03/integer-underflow-in-ap-mode-wmm-action-frame.txt wpa-2.3/debian/patches/2015-03/integer-underflow-in-ap-mode-wmm-action-frame.txt
--- wpa-2.3/debian/patches/2015-03/integer-underflow-in-ap-mode-wmm-action-frame.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-03/integer-underflow-in-ap-mode-wmm-action-frame.txt	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,58 @@
+Integer underflow in AP mode WMM Action frame processing
+
+Published: May 4, 2015
+Latest version available from: http://w1.fi/security/2015-3/
+
+
+Vulnerability
+
+A vulnerability was found in WMM Action frame processing in a case where
+hostapd or wpa_supplicant is used to implement AP mode MLME/SME
+functionality (i.e., Host AP driver of a mac80211-based driver on
+Linux).
+
+The AP mode WMM Action frame parser in hostapd/wpa_supplicant goes
+through the variable length information element part with the length of
+this area calculated by removing the header length from the total length
+of the frame. The frame length is previously verified to be large enough
+to include the IEEE 802.11 header, but the couple of additional bytes
+after this header are not explicitly verified and as a result of this,
+there may be an integer underflow that results in the signed integer
+variable storing the length becoming negative. This negative value is
+then interpreted as a very large unsigned integer length when parsing
+the information elements. This results in a buffer read overflow and
+process termination.
+
+This vulnerability can be used to perform denial of service attacks by
+an attacker that is within radio range of the AP that uses hostapd of
+wpa_supplicant for MLME/SME operations.
+
+
+Vulnerable versions/configurations
+
+hostapd v0.5.5-v2.4 with CONFIG_DRIVER_HOSTAP=y or
+CONFIG_DRIVER_NL80211=y in the build configuration (hostapd/.config).
+
+wpa_supplicant v0.7.0-v2.4 with CONFIG_AP=y or CONFIG_P2P=y and
+CONFIG_DRIVER_HOSTAP=y or CONFIG_DRIVER_NL80211=y in the build
+configuration (wpa_supplicant/.config) and AP (including P2P GO) mode
+used at runtime.
+
+
+Acknowledgments
+
+Thanks to Kostya Kortchinsky of Google Security Team for discovering and
+reporting this issue.
+
+
+Possible mitigation steps
+
+- Merge the following commit and rebuild hostapd/wpa_supplicant:
+
+  AP WMM: Fix integer underflow in WMM Action frame parser
+
+  This patch is available from http://w1.fi/security/2015-3/
+
+- Update to hostapd/wpa_supplicant v2.5 or newer, once available
+
+- wpa_supplicant: Do not enable AP mode or P2P GO operation at runtime
diff -Nru wpa-2.3/debian/patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch wpa-2.3/debian/patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
--- wpa-2.3/debian/patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,68 @@
+From dd2f043c9c43d156494e33d7ce22db96e6ef42c7 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Fri, 1 May 2015 16:37:45 +0300
+Subject: [PATCH 1/5] EAP-pwd peer: Fix payload length validation for Commit
+ and Confirm
+
+The length of the received Commit and Confirm message payloads was not
+checked before reading them. This could result in a buffer read
+overflow when processing an invalid message.
+
+Fix this by verifying that the payload is of expected length before
+processing it. In addition, enforce correct state transition sequence to
+make sure there is no unexpected behavior if receiving a Commit/Confirm
+message before the previous exchanges have been completed.
+
+Thanks to Kostya Kortchinsky of Google security team for discovering and
+reporting this issue.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/eap_peer/eap_pwd.c | 29 +++++++++++++++++++++++++++++
+ 1 file changed, 29 insertions(+)
+
+--- a/src/eap_peer/eap_pwd.c
++++ b/src/eap_peer/eap_pwd.c
+@@ -301,6 +301,23 @@ eap_pwd_perform_commit_exchange(struct e
+ 	BIGNUM *mask = NULL, *x = NULL, *y = NULL, *cofactor = NULL;
+ 	u16 offset;
+ 	u8 *ptr, *scalar = NULL, *element = NULL;
++	size_t prime_len, order_len;
++
++	if (data->state != PWD_Commit_Req) {
++		ret->ignore = TRUE;
++		goto fin;
++	}
++
++	prime_len = BN_num_bytes(data->grp->prime);
++	order_len = BN_num_bytes(data->grp->order);
++
++	if (payload_len != 2 * prime_len + order_len) {
++		wpa_printf(MSG_INFO,
++			   "EAP-pwd: Unexpected Commit payload length %u (expected %u)",
++			   (unsigned int) payload_len,
++			   (unsigned int) (2 * prime_len + order_len));
++		goto fin;
++	}
+ 
+ 	if (((data->private_value = BN_new()) == NULL) ||
+ 	    ((data->my_element = EC_POINT_new(data->grp->group)) == NULL) ||
+@@ -500,6 +517,18 @@ eap_pwd_perform_confirm_exchange(struct
+ 	u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
+ 	int offset;
+ 
++	if (data->state != PWD_Confirm_Req) {
++		ret->ignore = TRUE;
++		goto fin;
++	}
++
++	if (payload_len != SHA256_MAC_LEN) {
++		wpa_printf(MSG_INFO,
++			   "EAP-pwd: Unexpected Confirm payload length %u (expected %u)",
++			   (unsigned int) payload_len, SHA256_MAC_LEN);
++		goto fin;
++	}
++
+ 	/*
+ 	 * first build up the ciphersuite which is group | random_function |
+ 	 *	prf
diff -Nru wpa-2.3/debian/patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch wpa-2.3/debian/patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
--- wpa-2.3/debian/patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,61 @@
+From e28a58be26184c2a23f80b410e0997ef1bd5d578 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Fri, 1 May 2015 16:40:44 +0300
+Subject: [PATCH 2/5] EAP-pwd server: Fix payload length validation for Commit
+ and Confirm
+
+The length of the received Commit and Confirm message payloads was not
+checked before reading them. This could result in a buffer read
+overflow when processing an invalid message.
+
+Fix this by verifying that the payload is of expected length before
+processing it. In addition, enforce correct state transition sequence to
+make sure there is no unexpected behavior if receiving a Commit/Confirm
+message before the previous exchanges have been completed.
+
+Thanks to Kostya Kortchinsky of Google security team for discovering and
+reporting this issue.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/eap_server/eap_server_pwd.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/src/eap_server/eap_server_pwd.c
++++ b/src/eap_server/eap_server_pwd.c
+@@ -634,9 +634,21 @@ eap_pwd_process_commit_resp(struct eap_s
+ 	BIGNUM *x = NULL, *y = NULL, *cofactor = NULL;
+ 	EC_POINT *K = NULL, *point = NULL;
+ 	int res = 0;
++	size_t prime_len, order_len;
+ 
+ 	wpa_printf(MSG_DEBUG, "EAP-pwd: Received commit response");
+ 
++	prime_len = BN_num_bytes(data->grp->prime);
++	order_len = BN_num_bytes(data->grp->order);
++
++	if (payload_len != 2 * prime_len + order_len) {
++		wpa_printf(MSG_INFO,
++			   "EAP-pwd: Unexpected Commit payload length %u (expected %u)",
++			   (unsigned int) payload_len,
++			   (unsigned int) (2 * prime_len + order_len));
++		goto fin;
++	}
++
+ 	if (((data->peer_scalar = BN_new()) == NULL) ||
+ 	    ((data->k = BN_new()) == NULL) ||
+ 	    ((cofactor = BN_new()) == NULL) ||
+@@ -752,6 +764,13 @@ eap_pwd_process_confirm_resp(struct eap_
+ 	u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
+ 	int offset;
+ 
++	if (payload_len != SHA256_MAC_LEN) {
++		wpa_printf(MSG_INFO,
++			   "EAP-pwd: Unexpected Confirm payload length %u (expected %u)",
++			   (unsigned int) payload_len, SHA256_MAC_LEN);
++		goto fin;
++	}
++
+ 	/* build up the ciphersuite: group | random_function | prf */
+ 	grp = htons(data->group_num);
+ 	ptr = (u8 *) &cs;
diff -Nru wpa-2.3/debian/patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch wpa-2.3/debian/patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
--- wpa-2.3/debian/patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,47 @@
+From 477c74395acd0123340457ba6f15ab345d42016e Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Sat, 2 May 2015 19:23:04 +0300
+Subject: [PATCH 3/5] EAP-pwd peer: Fix Total-Length parsing for fragment
+ reassembly
+
+The remaining number of bytes in the message could be smaller than the
+Total-Length field size, so the length needs to be explicitly checked
+prior to reading the field and decrementing the len variable. This could
+have resulted in the remaining length becoming negative and interpreted
+as a huge positive integer.
+
+In addition, check that there is no already started fragment in progress
+before allocating a new buffer for reassembling fragments. This avoid a
+potential memory leak when processing invalid message.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/eap_peer/eap_pwd.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/src/eap_peer/eap_pwd.c
++++ b/src/eap_peer/eap_pwd.c
+@@ -812,11 +812,23 @@ eap_pwd_process(struct eap_sm *sm, void
+ 	 * if it's the first fragment there'll be a length field
+ 	 */
+ 	if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
++		if (len < 2) {
++			wpa_printf(MSG_DEBUG,
++				   "EAP-pwd: Frame too short to contain Total-Length field");
++			ret->ignore = TRUE;
++			return NULL;
++		}
+ 		tot_len = WPA_GET_BE16(pos);
+ 		wpa_printf(MSG_DEBUG, "EAP-pwd: Incoming fragments whose "
+ 			   "total length = %d", tot_len);
+ 		if (tot_len > 15000)
+ 			return NULL;
++		if (data->inbuf) {
++			wpa_printf(MSG_DEBUG,
++				   "EAP-pwd: Unexpected new fragment start when previous fragment is still in use");
++			ret->ignore = TRUE;
++			return NULL;
++		}
+ 		data->inbuf = wpabuf_alloc(tot_len);
+ 		if (data->inbuf == NULL) {
+ 			wpa_printf(MSG_INFO, "Out of memory to buffer "
diff -Nru wpa-2.3/debian/patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch wpa-2.3/debian/patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
--- wpa-2.3/debian/patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,45 @@
+From 3035cc2894e08319b905bd6561e8bddc8c2db9fa Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Sat, 2 May 2015 19:26:06 +0300
+Subject: [PATCH 4/5] EAP-pwd server: Fix Total-Length parsing for fragment
+ reassembly
+
+The remaining number of bytes in the message could be smaller than the
+Total-Length field size, so the length needs to be explicitly checked
+prior to reading the field and decrementing the len variable. This could
+have resulted in the remaining length becoming negative and interpreted
+as a huge positive integer.
+
+In addition, check that there is no already started fragment in progress
+before allocating a new buffer for reassembling fragments. This avoid a
+potential memory leak when processing invalid message.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/eap_server/eap_server_pwd.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/src/eap_server/eap_server_pwd.c
++++ b/src/eap_server/eap_server_pwd.c
+@@ -920,11 +920,21 @@ static void eap_pwd_process(struct eap_s
+ 	 * the first fragment has a total length
+ 	 */
+ 	if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
++		if (len < 2) {
++			wpa_printf(MSG_DEBUG,
++				   "EAP-pwd: Frame too short to contain Total-Length field");
++			return;
++		}
+ 		tot_len = WPA_GET_BE16(pos);
+ 		wpa_printf(MSG_DEBUG, "EAP-pwd: Incoming fragments, total "
+ 			   "length = %d", tot_len);
+ 		if (tot_len > 15000)
+ 			return;
++		if (data->inbuf) {
++			wpa_printf(MSG_DEBUG,
++				   "EAP-pwd: Unexpected new fragment start when previous fragment is still in use");
++			return;
++		}
+ 		data->inbuf = wpabuf_alloc(tot_len);
+ 		if (data->inbuf == NULL) {
+ 			wpa_printf(MSG_INFO, "EAP-pwd: Out of memory to "
diff -Nru wpa-2.3/debian/patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch wpa-2.3/debian/patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
--- wpa-2.3/debian/patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,27 @@
+From 28a069a545b06b99eb55ad53f63f2c99e65a98f6 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Sat, 2 May 2015 19:26:28 +0300
+Subject: [PATCH 5/5] EAP-pwd peer: Fix asymmetric fragmentation behavior
+
+The L (Length) and M (More) flags needs to be cleared before deciding
+whether the locally generated response requires fragmentation. This
+fixes an issue where these flags from the server could have been invalid
+for the following message. In some cases, this could have resulted in
+triggering the wpabuf security check that would terminate the process
+due to invalid buffer allocation.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/eap_peer/eap_pwd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/src/eap_peer/eap_pwd.c
++++ b/src/eap_peer/eap_pwd.c
+@@ -914,6 +914,7 @@ eap_pwd_process(struct eap_sm *sm, void
+ 	/*
+ 	 * we have output! Do we need to fragment it?
+ 	 */
++	lm_exch = EAP_PWD_GET_EXCHANGE(lm_exch);
+ 	len = wpabuf_len(data->outbuf);
+ 	if ((len + EAP_PWD_HDR_SIZE) > data->mtu) {
+ 		resp = eap_msg_alloc(EAP_VENDOR_IETF, EAP_TYPE_PWD, data->mtu,
diff -Nru wpa-2.3/debian/patches/2015-04/eap-pwd-missing-payload-length-validation.txt wpa-2.3/debian/patches/2015-04/eap-pwd-missing-payload-length-validation.txt
--- wpa-2.3/debian/patches/2015-04/eap-pwd-missing-payload-length-validation.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-04/eap-pwd-missing-payload-length-validation.txt	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,64 @@
+EAP-pwd missing payload length validation
+
+Published: May 4, 2015
+Latest version available from: http://w1.fi/security/2015-4/
+
+
+Vulnerability
+
+A vulnerability was found in EAP-pwd server and peer implementation used
+in hostapd and wpa_supplicant, respectively. The EAP-pwd/Commit and
+EAP-pwd/Confirm message payload is processed without verifying that the
+received frame is long enough to include all the fields. This results in
+buffer read overflow of up to couple of hundred bytes.
+
+The exact result of this buffer overflow depends on the platform and may
+be either not noticeable (i.e., authentication fails due to invalid data
+without any additional side effects) or process termination due to the
+buffer read overflow being detected and stopped. The latter case could
+potentially result in denial of service when EAP-pwd authentication is
+used.
+
+Further research into this issue found that the fragment reassembly
+processing is also missing a check for the Total-Length field and this
+could result in the payload length becoming negative. This itself would
+not add more to the vulnerability due to the payload length not being
+verified anyway. However, it is possible that a related reassembly step
+would result in hitting an internal security check on buffer use and
+result in the processing being terminated.
+
+
+Vulnerable versions/configurations
+
+hostapd v1.0-v2.4 with CONFIG_EAP_PWD=y in the build configuration
+(hostapd/.config) and EAP-pwd authentication server enabled in runtime
+configuration.
+
+wpa_supplicant v1.0-v2.4 with CONFIG_EAP_PWD=y in the build
+configuration (wpa_supplicant/.config) and EAP-pwd enabled in a network
+profile at runtime.
+
+
+Acknowledgments
+
+Thanks to Kostya Kortchinsky of Google Security Team for discovering and
+reporting this issue.
+
+
+Possible mitigation steps
+
+- Merge the following commits and rebuild hostapd/wpa_supplicant:
+
+  EAP-pwd peer: Fix payload length validation for Commit and Confirm
+  EAP-pwd server: Fix payload length validation for Commit and Confirm
+  EAP-pwd peer: Fix Total-Length parsing for fragment reassembly
+  EAP-pwd server: Fix Total-Length parsing for fragment reassembly
+  EAP-pwd peer: Fix asymmetric fragmentation behavior
+
+  These patches are available from http://w1.fi/security/2015-4/
+
+- Update to hostapd/wpa_supplicant v2.5 or newer, once available
+
+- Remove CONFIG_EAP_PWD=y from build configuration
+
+- Disable EAP-pwd in runtime configuration
diff -Nru wpa-2.3/debian/patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch wpa-2.3/debian/patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch
--- wpa-2.3/debian/patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-05/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,56 @@
+From df9079e72760ceb7ebe7fb11538200c516bdd886 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Tue, 7 Jul 2015 21:57:28 +0300
+Subject: [PATCH] NFC: Fix payload length validation in NDEF record parser
+
+It was possible for the 32-bit record->total_length value to end up
+wrapping around due to integer overflow if the longer form of payload
+length field is used and record->payload_length gets a value close to
+2^32. This could result in ndef_parse_record() accepting a too large
+payload length value and the record type filter reading up to about 20
+bytes beyond the end of the buffer and potentially killing the process.
+This could also result in an attempt to allocate close to 2^32 bytes of
+heap memory and if that were to succeed, a buffer read overflow of the
+same length which would most likely result in the process termination.
+In case of record->total_length ending up getting the value 0, there
+would be no buffer read overflow, but record parsing would result in an
+infinite loop in ndef_parse_records().
+
+Any of these error cases could potentially be used for denial of service
+attacks over NFC by using a malformed NDEF record on an NFC Tag or
+sending them during NFC connection handover if the application providing
+the NDEF message to hostapd/wpa_supplicant did no validation of the
+received records. While such validation is likely done in the NFC stack
+that needs to parse the NFC messages before further processing,
+hostapd/wpa_supplicant better be prepared for any data being included
+here.
+
+Fix this by validating record->payload_length value in a way that
+detects integer overflow. (CID 122668)
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/wps/ndef.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/src/wps/ndef.c
++++ b/src/wps/ndef.c
+@@ -48,6 +48,8 @@ static int ndef_parse_record(const u8 *d
+ 		if (size < 6)
+ 			return -1;
+ 		record->payload_length = ntohl(*(u32 *)pos);
++		if (record->payload_length > size - 6)
++			return -1;
+ 		pos += sizeof(u32);
+ 	}
+ 
+@@ -68,7 +70,8 @@ static int ndef_parse_record(const u8 *d
+ 	pos += record->payload_length;
+ 
+ 	record->total_length = pos - data;
+-	if (record->total_length > size)
++	if (record->total_length > size ||
++	    record->total_length < record->payload_length)
+ 		return -1;
+ 	return 0;
+ }
diff -Nru wpa-2.3/debian/patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt wpa-2.3/debian/patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt
--- wpa-2.3/debian/patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2015-05/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,87 @@
+Incomplete WPS and P2P NFC NDEF record payload length validation
+
+Published: July 8, 2015
+The latest version available from: http://w1.fi/security/2015-5/
+
+
+Vulnerability
+
+A vulnerability was found in NDEF record parsing implementation in
+hostapd and wpa_supplicant. This code is used when an NFC Tag or NFC
+connection handover is used to trigger WPS or P2P operations. The parser
+did include bounds checking for the NDEF record payload length, but due
+to insufficient integer size, it was possible to trigger integer
+overflow that would result in bypassing the validation step with some
+malformed NDEF records.
+
+This could result in denial of service due to hostapd/wpa_supplicant
+process termination (buffer read overflow) or infinite loop. The issue
+can be triggered only if the NFC stack on the device does not perform
+required validation steps for received NFC messages before sending the
+received message to hostapd/wpa_supplicant for processing.
+
+It was possible for the 32-bit record->total_length value to end up
+wrapping around due to integer overflow if the longer form of payload
+length field is used and record->payload_length gets a value close to
+2^32. This could result in ndef_parse_record() accepting a too large
+payload length value and the record type filter reading up to about 20
+bytes beyond the end of the buffer and potentially killing the process.
+This could also result in an attempt to allocate close to 2^32 bytes of
+heap memory and if that were to succeed, a buffer read overflow of the
+same length which would most likely result in the process termination.
+In case of record->total_length ending up getting the value 0, there
+would be no buffer read overflow, but record parsing would result in an
+infinite loop in ndef_parse_records().
+
+Any of these error cases could potentially be used for denial of service
+attacks over NFC by using a malformed NDEF record on an NFC Tag or
+sending them during NFC connection handover if the application providing
+the NDEF message to hostapd/wpa_supplicant did no validation of the
+received NDEF records. While such validation is likely done in the NFC
+stack that needs to parse the NFC messages before further processing,
+hostapd/wpa_supplicant should have (re)confirmed NDEF message validity
+properly.
+
+
+Vulnerable versions/configurations
+
+hostapd v0.7.0-v2.4 with CONFIG_WPS_NFC=y in the build configuration
+(hostapd/.config) and NFC NDEF records passed to hostapd by the NFC
+stack without validation.
+
+wpa_supplicant v0.7.0-v2.4 with CONFIG_WPS_NFC=y in the build
+configuration (wpa_supplicant/.config) and NFC NDEF records passed to
+wpa_supplicant by the NFC stack without validation.
+
+Note: No NFC stack implementation has yet been identified with
+capability to pass the malformed NDEF record to
+hostapd/wpa_supplicant. As such, it is not known whether this issue can
+be triggered in practice.
+
+Alternatively to an actual NFC operation trigger, the malformed NDEF
+records could be provided by other applications running on the same
+device if access to the hostapd/wpa_supplicant control interface is
+available to untrusted components or users.
+
+
+Acknowledgments
+
+Coverity Scan discovered parts of this issue (insecure data
+handling/TAINTED_SCALAR) and was the trigger for further manual review
+of the parsing routine.
+
+
+Possible mitigation steps
+
+- Merge the following commit and rebuild hostapd/wpa_supplicant:
+
+  NFC: Fix payload length validation in NDEF record parser
+
+  This patch is available from http://w1.fi/security/2015-5/
+
+- Update to hostapd/wpa_supplicant v2.5 or newer, once available
+
+- Remove CONFIG_WPS_NFC=y from build configuration
+
+- Confirm that the NFC stack does sufficient validation of the received
+  NDEF records before passing them to hostapd/wpa_supplicant
diff -Nru wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
--- wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/2015-4/0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch	2016-07-21 09:19:32.000000000 +0200
@@ -25,7 +25,7 @@
 index f2b0926..a629437 100644
 --- a/src/eap_peer/eap_pwd.c
 +++ b/src/eap_peer/eap_pwd.c
-@@ -355,6 +355,23 @@ eap_pwd_perform_commit_exchange(struct eap_sm *sm, struct eap_pwd_data *data,
+@@ -301,6 +301,23 @@
  	BIGNUM *mask = NULL, *x = NULL, *y = NULL, *cofactor = NULL;
  	u16 offset;
  	u8 *ptr, *scalar = NULL, *element = NULL;
@@ -49,7 +49,7 @@
  
  	if (((data->private_value = BN_new()) == NULL) ||
  	    ((data->my_element = EC_POINT_new(data->grp->group)) == NULL) ||
-@@ -554,6 +571,18 @@ eap_pwd_perform_confirm_exchange(struct eap_sm *sm, struct eap_pwd_data *data,
+@@ -500,6 +517,18 @@
  	u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
  	int offset;
  
diff -Nru wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
--- wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/2015-4/0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch	2016-07-21 09:19:32.000000000 +0200
@@ -25,7 +25,7 @@
 index 66bd5d2..3189105 100644
 --- a/src/eap_server/eap_server_pwd.c
 +++ b/src/eap_server/eap_server_pwd.c
-@@ -656,9 +656,21 @@ eap_pwd_process_commit_resp(struct eap_sm *sm, struct eap_pwd_data *data,
+@@ -634,9 +634,21 @@
  	BIGNUM *x = NULL, *y = NULL, *cofactor = NULL;
  	EC_POINT *K = NULL, *point = NULL;
  	int res = 0;
@@ -47,7 +47,7 @@
  	if (((data->peer_scalar = BN_new()) == NULL) ||
  	    ((data->k = BN_new()) == NULL) ||
  	    ((cofactor = BN_new()) == NULL) ||
-@@ -774,6 +786,13 @@ eap_pwd_process_confirm_resp(struct eap_sm *sm, struct eap_pwd_data *data,
+@@ -752,6 +764,13 @@
  	u8 conf[SHA256_MAC_LEN], *cruft = NULL, *ptr;
  	int offset;
  
diff -Nru wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
--- wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/2015-4/0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch	2016-07-21 09:19:32.000000000 +0200
@@ -23,7 +23,7 @@
 index a629437..1d2079b 100644
 --- a/src/eap_peer/eap_pwd.c
 +++ b/src/eap_peer/eap_pwd.c
-@@ -866,11 +866,23 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct eap_method_ret *ret,
+@@ -812,11 +812,23 @@
  	 * if it's the first fragment there'll be a length field
  	 */
  	if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
diff -Nru wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
--- wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/2015-4/0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch	2016-07-21 09:19:32.000000000 +0200
@@ -23,7 +23,7 @@
 index 3189105..2bfc3c2 100644
 --- a/src/eap_server/eap_server_pwd.c
 +++ b/src/eap_server/eap_server_pwd.c
-@@ -942,11 +942,21 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+@@ -920,11 +920,21 @@
  	 * the first fragment has a total length
  	 */
  	if (EAP_PWD_GET_LENGTH_BIT(lm_exch)) {
diff -Nru wpa-2.3/debian/patches/2015-4/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch wpa-2.3/debian/patches/2015-4/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
--- wpa-2.3/debian/patches/2015-4/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/2015-4/0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch	2016-07-21 09:19:32.000000000 +0200
@@ -19,7 +19,7 @@
 index 1d2079b..e58b13a 100644
 --- a/src/eap_peer/eap_pwd.c
 +++ b/src/eap_peer/eap_pwd.c
-@@ -968,6 +968,7 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct eap_method_ret *ret,
+@@ -914,6 +914,7 @@
  	/*
  	 * we have output! Do we need to fragment it?
  	 */
diff -Nru wpa-2.3/debian/patches/2016-1/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch wpa-2.3/debian/patches/2016-1/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
--- wpa-2.3/debian/patches/2016-1/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,73 @@
+From ecbb0b3dc122b0d290987cf9c84010bbe53e1022 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri, 4 Mar 2016 17:20:18 +0200
+Subject: [PATCH 1/5] WPS: Reject a Credential with invalid passphrase
+
+WPA/WPA2-Personal passphrase is not allowed to include control
+characters. Reject a Credential received from a WPS Registrar both as
+STA (Credential) and AP (AP Settings) if the credential is for WPAPSK or
+WPA2PSK authentication type and includes an invalid passphrase.
+
+This fixes an issue where hostapd or wpa_supplicant could have updated
+the configuration file PSK/passphrase parameter with arbitrary data from
+an external device (Registrar) that may not be fully trusted. Should
+such data include a newline character, the resulting configuration file
+could become invalid and fail to be parsed.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ src/utils/common.c         | 12 ++++++++++++
+ src/utils/common.h         |  1 +
+ src/wps/wps_attr_process.c | 10 ++++++++++
+ 3 files changed, 23 insertions(+)
+
+--- a/src/utils/common.c
++++ b/src/utils/common.c
+@@ -593,6 +593,18 @@ int find_first_bit(u32 value)
+ }
+ 
+ 
++int has_ctrl_char(const u8 *data, size_t len)
++{
++	size_t i;
++
++	for (i = 0; i < len; i++) {
++		if (data[i] < 32 || data[i] == 127)
++			return 1;
++	}
++	return 0;
++}
++
++
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+ 			 const u8 *src1, size_t src1_len,
+ 			 const u8 *src2, size_t src2_len)
+--- a/src/utils/common.h
++++ b/src/utils/common.h
+@@ -493,6 +493,7 @@ const char * wpa_ssid_txt(const u8 *ssid
+ 
+ char * wpa_config_parse_string(const char *value, size_t *len);
+ int is_hex(const u8 *data, size_t len);
++int has_ctrl_char(const u8 *data, size_t len);
+ int find_first_bit(u32 value);
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+ 			 const u8 *src1, size_t src1_len,
+--- a/src/wps/wps_attr_process.c
++++ b/src/wps/wps_attr_process.c
+@@ -229,6 +229,16 @@ static int wps_workaround_cred_key(struc
+ 		cred->key_len--;
+ #endif /* CONFIG_WPS_STRICT */
+ 	}
++
++
++	if (cred->auth_type & (WPS_AUTH_WPAPSK | WPS_AUTH_WPA2PSK) &&
++	    (cred->key_len < 8 || has_ctrl_char(cred->key, cred->key_len))) {
++		wpa_printf(MSG_INFO, "WPS: Reject credential with invalid WPA/WPA2-Personal passphrase");
++		wpa_hexdump_ascii_key(MSG_INFO, "WPS: Network Key",
++				      cred->key, cred->key_len);
++		return -1;
++	}
++
+ 	return 0;
+ }
+ 
diff -Nru wpa-2.3/debian/patches/2016-1/0002-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch wpa-2.3/debian/patches/2016-1/0002-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
--- wpa-2.3/debian/patches/2016-1/0002-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/0002-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,46 @@
+From 73e4abb24a936014727924d8b0b2965edfc117dd Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri, 4 Mar 2016 18:46:41 +0200
+Subject: [PATCH 2/5] Reject psk parameter set with invalid passphrase
+ character
+
+WPA/WPA2-Personal passphrase is not allowed to include control
+characters. Reject a passphrase configuration attempt if that passphrase
+includes an invalid passphrase.
+
+This fixes an issue where wpa_supplicant could have updated the
+configuration file psk parameter with arbitrary data from the control
+interface or D-Bus interface. While those interfaces are supposed to be
+accessible only for trusted users/applications, it may be possible that
+an untrusted user has access to a management software component that
+does not validate the passphrase value before passing it to
+wpa_supplicant.
+
+This could allow such an untrusted user to inject up to 63 characters of
+almost arbitrary data into the configuration file. Such configuration
+file could result in wpa_supplicant trying to load a library (e.g.,
+opensc_engine_path, pkcs11_engine_path, pkcs11_module_path,
+load_dynamic_eap) from user controlled location when starting again.
+This would allow code from that library to be executed under the
+wpa_supplicant process privileges.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ wpa_supplicant/config.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/wpa_supplicant/config.c
++++ b/wpa_supplicant/config.c
+@@ -318,6 +318,12 @@ static int wpa_config_parse_psk(const st
+ 		}
+ 		wpa_hexdump_ascii_key(MSG_MSGDUMP, "PSK (ASCII passphrase)",
+ 				      (u8 *) value, len);
++		if (has_ctrl_char((u8 *) value, len)) {
++			wpa_printf(MSG_ERROR,
++				   "Line %d: Invalid passphrase character",
++				   line);
++			return -1;
++		}
+ 		if (ssid->passphrase && os_strlen(ssid->passphrase) == len &&
+ 		    os_memcmp(ssid->passphrase, value, len) == 0)
+ 			return 0;
diff -Nru wpa-2.3/debian/patches/2016-1/0003-Remove-newlines-from-wpa_supplicant-config-network-o.patch wpa-2.3/debian/patches/2016-1/0003-Remove-newlines-from-wpa_supplicant-config-network-o.patch
--- wpa-2.3/debian/patches/2016-1/0003-Remove-newlines-from-wpa_supplicant-config-network-o.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/0003-Remove-newlines-from-wpa_supplicant-config-network-o.patch	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,73 @@
+From 0fe5a234240a108b294a87174ad197f6b5cb38e9 Mon Sep 17 00:00:00 2001
+From: Paul Stewart <ps...@google.com>
+Date: Thu, 3 Mar 2016 15:40:19 -0800
+Subject: [PATCH 3/5] Remove newlines from wpa_supplicant config network
+ output
+
+Spurious newlines output while writing the config file can corrupt the
+wpa_supplicant configuration. Avoid writing these for the network block
+parameters. This is a generic filter that cover cases that may not have
+been explicitly addressed with a more specific commit to avoid control
+characters in the psk parameter.
+
+Signed-off-by: Paul Stewart <ps...@google.com>
+---
+ src/utils/common.c      | 11 +++++++++++
+ src/utils/common.h      |  1 +
+ wpa_supplicant/config.c | 15 +++++++++++++--
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+--- a/src/utils/common.c
++++ b/src/utils/common.c
+@@ -605,6 +605,17 @@ int has_ctrl_char(const u8 *data, size_t
+ }
+ 
+ 
++int has_newline(const char *str)
++{
++	while (*str) {
++		if (*str == '\n' || *str == '\r')
++			return 1;
++		str++;
++	}
++	return 0;
++}
++
++
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+ 			 const u8 *src1, size_t src1_len,
+ 			 const u8 *src2, size_t src2_len)
+--- a/src/utils/common.h
++++ b/src/utils/common.h
+@@ -494,6 +494,7 @@ const char * wpa_ssid_txt(const u8 *ssid
+ char * wpa_config_parse_string(const char *value, size_t *len);
+ int is_hex(const u8 *data, size_t len);
+ int has_ctrl_char(const u8 *data, size_t len);
++int has_newline(const char *str);
+ int find_first_bit(u32 value);
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+ 			 const u8 *src1, size_t src1_len,
+--- a/wpa_supplicant/config.c
++++ b/wpa_supplicant/config.c
+@@ -2375,8 +2375,19 @@ char * wpa_config_get(struct wpa_ssid *s
+ 
+ 	for (i = 0; i < NUM_SSID_FIELDS; i++) {
+ 		const struct parse_data *field = &ssid_fields[i];
+-		if (os_strcmp(var, field->name) == 0)
+-			return field->writer(field, ssid);
++		if (os_strcmp(var, field->name) == 0) {
++			char *ret = field->writer(field, ssid);
++
++			if (ret && has_newline(ret)) {
++				wpa_printf(MSG_ERROR,
++					   "Found newline in value for %s; not returning it",
++					   var);
++				os_free(ret);
++				ret = NULL;
++			}
++
++			return ret;
++		}
+ 	}
+ 
+ 	return NULL;
diff -Nru wpa-2.3/debian/patches/2016-1/0004-Reject-SET_CRED-commands-with-newline-characters-in-.patch wpa-2.3/debian/patches/2016-1/0004-Reject-SET_CRED-commands-with-newline-characters-in-.patch
--- wpa-2.3/debian/patches/2016-1/0004-Reject-SET_CRED-commands-with-newline-characters-in-.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/0004-Reject-SET_CRED-commands-with-newline-characters-in-.patch	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,57 @@
+From b166cd84a77a6717be9600bf95378a0055d6f5a5 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Tue, 5 Apr 2016 23:33:10 +0300
+Subject: [PATCH 4/5] Reject SET_CRED commands with newline characters in the
+ string values
+
+Most of the cred block parameters are written as strings without
+filtering and if there is an embedded newline character in the value,
+unexpected configuration file data might be written.
+
+This fixes an issue where wpa_supplicant could have updated the
+configuration file cred parameter with arbitrary data from the control
+interface or D-Bus interface. While those interfaces are supposed to be
+accessible only for trusted users/applications, it may be possible that
+an untrusted user has access to a management software component that
+does not validate the credential value before passing it to
+wpa_supplicant.
+
+This could allow such an untrusted user to inject almost arbitrary data
+into the configuration file. Such configuration file could result in
+wpa_supplicant trying to load a library (e.g., opensc_engine_path,
+pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user
+controlled location when starting again. This would allow code from that
+library to be executed under the wpa_supplicant process privileges.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ wpa_supplicant/config.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/wpa_supplicant/config.c
++++ b/wpa_supplicant/config.c
+@@ -2572,6 +2572,8 @@ int wpa_config_set_cred(struct wpa_cred
+ 
+ 	if (os_strcmp(var, "password") == 0 &&
+ 	    os_strncmp(value, "ext:", 4) == 0) {
++		if (has_newline(value))
++			return -1;
+ 		str_clear_free(cred->password);
+ 		cred->password = os_strdup(value);
+ 		cred->ext_password = 1;
+@@ -2622,9 +2624,14 @@ int wpa_config_set_cred(struct wpa_cred
+ 	}
+ 
+ 	val = wpa_config_parse_string(value, &len);
+-	if (val == NULL) {
++	if (val == NULL ||
++	    (os_strcmp(var, "excluded_ssid") != 0 &&
++	     os_strcmp(var, "roaming_consortium") != 0 &&
++	     os_strcmp(var, "required_roaming_consortium") != 0 &&
++	     has_newline(val))) {
+ 		wpa_printf(MSG_ERROR, "Line %d: invalid field '%s' string "
+ 			   "value '%s'.", line, var, value);
++		os_free(val);
+ 		return -1;
+ 	}
+ 
diff -Nru wpa-2.3/debian/patches/2016-1/0005-Reject-SET-commands-with-newline-characters-in-the-s.patch wpa-2.3/debian/patches/2016-1/0005-Reject-SET-commands-with-newline-characters-in-the-s.patch
--- wpa-2.3/debian/patches/2016-1/0005-Reject-SET-commands-with-newline-characters-in-the-s.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/0005-Reject-SET-commands-with-newline-characters-in-the-s.patch	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,45 @@
+From 2a3f56502b52375c3bf113cf92adfa99bad6b488 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Tue, 5 Apr 2016 23:55:48 +0300
+Subject: [PATCH 5/5] Reject SET commands with newline characters in the
+ string values
+
+Many of the global configuration parameters are written as strings
+without filtering and if there is an embedded newline character in the
+value, unexpected configuration file data might be written.
+
+This fixes an issue where wpa_supplicant could have updated the
+configuration file global parameter with arbitrary data from the control
+interface or D-Bus interface. While those interfaces are supposed to be
+accessible only for trusted users/applications, it may be possible that
+an untrusted user has access to a management software component that
+does not validate the value of a parameter before passing it to
+wpa_supplicant.
+
+This could allow such an untrusted user to inject almost arbitrary data
+into the configuration file. Such configuration file could result in
+wpa_supplicant trying to load a library (e.g., opensc_engine_path,
+pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user
+controlled location when starting again. This would allow code from that
+library to be executed under the wpa_supplicant process privileges.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ wpa_supplicant/config.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/wpa_supplicant/config.c
++++ b/wpa_supplicant/config.c
+@@ -3418,6 +3418,12 @@ static int wpa_global_config_parse_str(c
+ 		return -1;
+ 	}
+ 
++	if (has_newline(pos)) {
++		wpa_printf(MSG_ERROR, "Line %d: invalid %s value with newline",
++			   line, data->name);
++		return -1;
++	}
++
+ 	tmp = os_strdup(pos);
+ 	if (tmp == NULL)
+ 		return -1;
diff -Nru wpa-2.3/debian/patches/2016-1/psk-parameter-config-update.txt wpa-2.3/debian/patches/2016-1/psk-parameter-config-update.txt
--- wpa-2.3/debian/patches/2016-1/psk-parameter-config-update.txt	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/2016-1/psk-parameter-config-update.txt	2016-07-21 09:19:32.000000000 +0200
@@ -0,0 +1,101 @@
+psk configuration parameter update allowing arbitrary data to be written
+
+Published: May 2, 2016
+Identifiers: CVE-2016-4476 and CVE-2016-4477
+   (CVE-2016-2447 is an instance of CVE-2016-4477 on Android)
+Latest version available from: http://w1.fi/security/2016-1/
+
+
+Vulnerability
+
+A vulnerability was found in how hostapd and wpa_supplicant writes the
+configuration file update for the WPA/WPA2 passphrase parameter. If this
+parameter has been updated to include control characters either through
+a WPS operation (CVE-2016-4476) or through local configuration change
+over the wpa_supplicant control interface (CVE-2016-4477), the resulting
+configuration file may prevent the hostapd and wpa_supplicant from
+starting when the updated file is used. In addition for wpa_supplicant,
+it may be possible to load a local library file and execute code from
+there with the same privileges under which the wpa_supplicant process
+runs.
+
+The WPS trigger for this requires local user action to authorize the WPS
+operation in which a new configuration would be received. The attacker
+would also need to be in radio range of the device or have access to the
+IP network to act as a WPS External Registrar. Such an attack could
+result in denial of service by not allowing hostapd or wpa_supplicant to
+start after they have been stopped.
+
+The local configuration update through the control interface SET_NETWORK
+command could allow privilege escalation for the local user to run code
+from a locally stored library file under the same privileges as the
+wpa_supplicant process has. The assumption here is that a not fully
+trusted user/application might have access through a connection manager
+to set network profile parameters like psk, but would not have access to
+set other configuration file parameters. If the connection manager in
+such a case does not filter out control characters from the psk value,
+it could have been possible to practically update the global parameters
+by embedding a newline character within the psk value. In addition, the
+untrusted user/application would need to be able to install a library
+file somewhere on the device from where the wpa_supplicant process has
+privileges to load the library.
+
+Similarly to the SET_NETWORK case, if a connection manager exposes
+access to the SET_CRED or SET commands, similar issue with newline
+characters can exist as those commands do not filter out control
+characters from the value.
+
+It should also be noted that providing unlimited access to the
+wpa_supplicant control interface would allow arbitrary SET commands to
+be issued. Such unlimited access should not be provided to untrusted
+users/applications.
+
+
+Vulnerable versions/configurations
+
+For the local control interface attack vector (CVE-2016-4477):
+
+wpa_supplicant v0.4.0-v2.5 with control interface enabled
+
+update_config=1 must have been enabled in the configuration file.
+
+
+For the WPS attack vector (CVE-2016-4476):
+
+wpa_supplicant v0.6.7-v2.5 with CONFIG_WPS build option enabled
+hostapd v0.6.7-v2.5 with CONFIG_WPS build option enabled
+
+WPS needs to be enabled in the runtime operation and the WPS operation
+needs to have been authorized by the local user over the control
+interface. For wpa_supplicant, update_config=1 must have been enabled in
+the configuration file.
+
+
+Acknowledgments
+
+Thanks to Google for reporting this issue and Imre Rad of SEARCH-LAB
+Ltd. discovering it.
+
+
+Possible mitigation steps
+
+- Merge the following commits to hostapd/wpa_supplicant and rebuild it:
+
+  CVE-2016-4476:
+  WPS: Reject a Credential with invalid passphrase
+  CVE-2016-4477:
+  Reject psk parameter set with invalid passphrase character
+  Reject SET_CRED commands with newline characters in the string values
+  Reject SET commands with newline characters in the string values
+  CVE-2016-4476 and CVE-2016-4477:
+  Remove newlines from wpa_supplicant config network output
+
+  These patches are available from http://w1.fi/security/2016-1/
+
+- Update to hostapd/wpa_supplicant v2.6 or newer, once available
+
+
+Change history
+
+May 3, 2016
+- Added CVE IDs
diff -Nru wpa-2.3/debian/patches/ap_config_c_fix-typo-for-capabilities.patch wpa-2.3/debian/patches/ap_config_c_fix-typo-for-capabilities.patch
--- wpa-2.3/debian/patches/ap_config_c_fix-typo-for-capabilities.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/ap_config_c_fix-typo-for-capabilities.patch	2016-07-20 23:23:46.000000000 +0200
@@ -0,0 +1,28 @@
+From 01be02b9ff763dad3567b7f3079b5d3932d2e3ea Mon Sep 17 00:00:00 2001
+From: Stefan Lippers-Hollmann <s....@gmx.de>
+Date: Wed, 17 Sep 2014 00:59:11 +0200
+Subject: [PATCH] ap_config.c: fix typo for "capabilities"
+
+Signed-off-by: Stefan Lippers-Hollmann <s....@gmx.de>
+---
+http://lists.shmoo.com/pipermail/hostap/2014-September/030883.html
+
+ src/ap/ap_config.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/ap/ap_config.c b/src/ap/ap_config.c
+index bc9f6cf..d7d5c3b 100644
+--- a/src/ap/ap_config.c
++++ b/src/ap/ap_config.c
+@@ -759,7 +759,7 @@ static int hostapd_config_check_bss(struct hostapd_bss_config *bss,
+ 	    conf->hw_mode == HOSTAPD_MODE_IEEE80211B) {
+ 		bss->disable_11n = 1;
+ 		wpa_printf(MSG_ERROR, "HT (IEEE 802.11n) in 11b mode is not "
+-			   "allowed, disabling HT capabilites");
++			   "allowed, disabling HT capabilities");
+ 	}
+ 
+ 	if (full_config && conf->ieee80211n &&
+-- 
+2.1.0
+
diff -Nru wpa-2.3/debian/patches/CVE-2015-5314.patch wpa-2.3/debian/patches/CVE-2015-5314.patch
--- wpa-2.3/debian/patches/CVE-2015-5314.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/CVE-2015-5314.patch	2016-07-21 09:19:32.000000000 +0200
@@ -16,7 +16,7 @@
 index cb83ff7..9f787ab 100644
 --- a/src/eap_server/eap_server_pwd.c
 +++ b/src/eap_server/eap_server_pwd.c
-@@ -970,7 +970,7 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+@@ -947,7 +947,7 @@
  	/*
  	 * the first and all intermediate fragments have the M bit set
  	 */
@@ -25,7 +25,7 @@
  		if ((data->in_frag_pos + len) > wpabuf_size(data->inbuf)) {
  			wpa_printf(MSG_DEBUG, "EAP-pwd: Buffer overflow "
  				   "attack detected! (%d+%d > %d)",
-@@ -981,6 +981,8 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+@@ -958,6 +958,8 @@
  		}
  		wpabuf_put_data(data->inbuf, pos, len);
  		data->in_frag_pos += len;
@@ -34,7 +34,7 @@
  		wpa_printf(MSG_DEBUG, "EAP-pwd: Got a %d byte fragment",
  			   (int) len);
  		return;
-@@ -990,8 +992,6 @@ static void eap_pwd_process(struct eap_sm *sm, void *priv,
+@@ -967,8 +969,6 @@
  	 * buffering fragments so that's how we know it's the last)
  	 */
  	if (data->in_frag_pos) {
diff -Nru wpa-2.3/debian/patches/CVE-2015-5315.patch wpa-2.3/debian/patches/CVE-2015-5315.patch
--- wpa-2.3/debian/patches/CVE-2015-5315.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/CVE-2015-5315.patch	2016-07-21 09:19:32.000000000 +0200
@@ -16,7 +16,7 @@
 index 1f78544..75ceef1 100644
 --- a/src/eap_peer/eap_pwd.c
 +++ b/src/eap_peer/eap_pwd.c
-@@ -903,7 +903,7 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct eap_method_ret *ret,
+@@ -841,7 +841,7 @@
  	/*
  	 * buffer and ACK the fragment
  	 */
@@ -25,7 +25,7 @@
  		data->in_frag_pos += len;
  		if (data->in_frag_pos > wpabuf_size(data->inbuf)) {
  			wpa_printf(MSG_INFO, "EAP-pwd: Buffer overflow attack "
-@@ -916,7 +916,8 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct eap_method_ret *ret,
+@@ -854,7 +854,8 @@
  			return NULL;
  		}
  		wpabuf_put_data(data->inbuf, pos, len);
@@ -35,7 +35,7 @@
  		resp = eap_msg_alloc(EAP_VENDOR_IETF, EAP_TYPE_PWD,
  				     EAP_PWD_HDR_SIZE,
  				     EAP_CODE_RESPONSE, eap_get_id(reqData));
-@@ -930,10 +931,8 @@ eap_pwd_process(struct eap_sm *sm, void *priv, struct eap_method_ret *ret,
+@@ -868,10 +869,8 @@
  	 * we're buffering and this is the last fragment
  	 */
  	if (data->in_frag_pos) {
diff -Nru wpa-2.3/debian/patches/CVE-2015-5316.patch wpa-2.3/debian/patches/CVE-2015-5316.patch
--- wpa-2.3/debian/patches/CVE-2015-5316.patch	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/CVE-2015-5316.patch	2016-07-21 09:19:32.000000000 +0200
@@ -16,7 +16,7 @@
 index 75ceef1..892b590 100644
 --- a/src/eap_peer/eap_pwd.c
 +++ b/src/eap_peer/eap_pwd.c
-@@ -774,7 +774,8 @@ eap_pwd_perform_confirm_exchange(struct eap_sm *sm, struct eap_pwd_data *data,
+@@ -713,7 +713,8 @@
  	wpabuf_put_data(data->outbuf, conf, SHA256_MAC_LEN);
  
  fin:
diff -Nru wpa-2.3/debian/patches/fix-minor-issue-in-HT40-max-rate-determination.patch wpa-2.3/debian/patches/fix-minor-issue-in-HT40-max-rate-determination.patch
--- wpa-2.3/debian/patches/fix-minor-issue-in-HT40-max-rate-determination.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/fix-minor-issue-in-HT40-max-rate-determination.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,25 @@
+From 8b2b718da9884d66684befe99d1fbdd9abe5fb5e Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Sat, 28 Feb 2015 16:35:07 +0200
+Subject: Fix minor issue in HT40 max rate determination
+
+Commit a1b790eb9d7514d1a6e0582a07f695a1564caa59 ('Select AP based on
+estimated maximum throughput') had a copy-paste bug than ended up
+leaving one of the max_ht40_rate() cases unreachable. (CID 106087)
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ wpa_supplicant/scan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/wpa_supplicant/scan.c
++++ b/wpa_supplicant/scan.c
+@@ -1810,7 +1810,7 @@ static unsigned int max_ht40_rate(int sn
+ 		return 81000; /* HT40 MCS4 */
+ 	if (snr < 22)
+ 		return 108000; /* HT40 MCS5 */
+-	if (snr < 22)
++	if (snr < 24)
+ 		return 121500; /* HT40 MCS6 */
+ 	return 135000; /* HT40 MCS7 */
+ }
diff -Nru wpa-2.3/debian/patches/fix-spelling-s-algorith-algorithm.patch wpa-2.3/debian/patches/fix-spelling-s-algorith-algorithm.patch
--- wpa-2.3/debian/patches/fix-spelling-s-algorith-algorithm.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/fix-spelling-s-algorith-algorithm.patch	2016-07-20 23:13:41.000000000 +0200
@@ -0,0 +1,25 @@
+From fe3e5d3dd7deebe49e47b2b757409fe5adcdae7e Mon Sep 17 00:00:00 2001
+From: Stefan Lippers-Hollmann <s....@gmx.de>
+Date: Thu, 20 Feb 2014 22:09:19 +0100
+Subject: [PATCH] fix spelling s/algorith/algorithm/
+
+Signed-off-by: Stefan Lippers-Hollmann <s....@gmx.de>
+---
+submitted upstream
+ Message-Id: <201402202119.15847.s....@gmx.de>
+ http://lists.shmoo.com/pipermail/hostap/2014-February/029580.html
+
+ src/eap_peer/eap_aka.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/eap_peer/eap_aka.c
++++ b/src/eap_peer/eap_aka.c
+@@ -316,7 +316,7 @@ static int eap_aka_umts_auth(struct eap_
+ 
+ #else /* CONFIG_USIM_HARDCODED */
+ 
+-	wpa_printf(MSG_DEBUG, "EAP-AKA: No UMTS authentication algorith "
++	wpa_printf(MSG_DEBUG, "EAP-AKA: No UMTS authentication algorithm "
+ 		   "enabled");
+ 	return -1;
+ 
diff -Nru wpa-2.3/debian/patches/improve-BSS-selection-with-default-noise-floor-value.patch wpa-2.3/debian/patches/improve-BSS-selection-with-default-noise-floor-value.patch
--- wpa-2.3/debian/patches/improve-BSS-selection-with-default-noise-floor-value.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/improve-BSS-selection-with-default-noise-floor-value.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,158 @@
+From f0d0a5d23bd406a60358add9fa101b49dc9f9039 Mon Sep 17 00:00:00 2001
+From: Mukesh Agrawal <qui...@chromium.org>
+Date: Tue, 8 Apr 2014 17:54:49 -0700
+Subject: Improve BSS selection with default noise floor values
+
+When noise floor measurements are not available, compute SNR
+using default values for the noise floor. This helps steer us
+towards 5 GHz BSSes in high signal strength environments.
+
+In more detail...
+
+Existing code prefers a 5 GHz BSS when the 5 GHz BSS's signal
+strength is "close" to that of the 2.4 GHz BSS, or when both SNRs
+are large. However, the mwifiex driver does not provide noise
+floor measurements, so we can't compute SNRs.
+
+Because mwifiex doesn't provide NF measurements, the "large SNR"
+code wasn't effective. By using default values for the noise floor,
+we can again compute SNRs, and decide that the SNR is high enough
+that we shouldn't worry about the exact difference in SNR.
+
+The default noise floor values (one for 2.4 GHz, and one for 5 GHz)
+were chosen by measurement in a noisy environment, so they should be
+conservative.
+
+Note that while this patch is motivated by mwifiex, it affects
+ath9k as well. Although ath9k provides noise floor measurements
+in general, it will sometimes fail to provide a measurement for
+one or more specific channels.
+
+As a result of this patch, we'll always compare BSSes based on SNR
+(either measured or estimated), rather than sometimes comparing
+based on signal strength. ("Always" assumes that the
+WPA_SCAN_LEVEL_DBM flag is set. It is for mwifiex and ath9k.)
+
+While there:
+- fix a whitespace issue (spaces -> tab)
+- clean up existing comments
+- update dump_scan_res to indicate whether the noise floor is
+  measured, or default
+
+Signed-hostap: mukesh agrawal <qui...@chromium.org>
+---
+ wpa_supplicant/scan.c | 47 ++++++++++++++++++++++++++++++++---------------
+ 1 file changed, 32 insertions(+), 15 deletions(-)
+
+--- a/wpa_supplicant/scan.c
++++ b/wpa_supplicant/scan.c
+@@ -1543,11 +1543,12 @@ struct wpabuf * wpa_scan_get_vendor_ie_m
+  */
+ #define GREAT_SNR 30
+ 
++#define IS_5GHZ(n) (n > 4000)
++
+ /* Compare function for sorting scan results. Return >0 if @b is considered
+  * better. */
+ static int wpa_scan_result_compar(const void *a, const void *b)
+ {
+-#define IS_5GHZ(n) (n > 4000)
+ #define MIN(a,b) a < b ? a : b
+ 	struct wpa_scan_res **_wa = (void *) a;
+ 	struct wpa_scan_res **_wb = (void *) b;
+@@ -1575,18 +1576,18 @@ static int wpa_scan_result_compar(const
+ 	    (wb->caps & IEEE80211_CAP_PRIVACY) == 0)
+ 		return -1;
+ 
+-	if ((wa->flags & wb->flags & WPA_SCAN_LEVEL_DBM) &&
+-	    !((wa->flags | wb->flags) & WPA_SCAN_NOISE_INVALID)) {
++	if (wa->flags & wb->flags & WPA_SCAN_LEVEL_DBM) {
+ 		snr_a = MIN(wa->level - wa->noise, GREAT_SNR);
+ 		snr_b = MIN(wb->level - wb->noise, GREAT_SNR);
+ 	} else {
+-		/* Not suitable information to calculate SNR, so use level */
++		/* Level is not in dBm, so we can't calculate
++		 * SNR. Just use raw level (units unknown). */
+ 		snr_a = wa->level;
+ 		snr_b = wb->level;
+ 	}
+ 
+-	/* best/max rate preferred if SNR close enough */
+-        if ((snr_a && snr_b && abs(snr_b - snr_a) < 5) ||
++	/* if SNR is close, decide by max rate or frequency band */
++	if ((snr_a && snr_b && abs(snr_b - snr_a) < 5) ||
+ 	    (wa->qual && wb->qual && abs(wb->qual - wa->qual) < 10)) {
+ 		maxrate_a = wpa_scan_get_max_rate(wa);
+ 		maxrate_b = wpa_scan_get_max_rate(wb);
+@@ -1596,8 +1597,6 @@ static int wpa_scan_result_compar(const
+ 			return IS_5GHZ(wa->freq) ? -1 : 1;
+ 	}
+ 
+-	/* use freq for channel preference */
+-
+ 	/* all things being equal, use SNR; if SNRs are
+ 	 * identical, use quality values since some drivers may only report
+ 	 * that value and leave the signal level zero */
+@@ -1605,7 +1604,6 @@ static int wpa_scan_result_compar(const
+ 		return wb->qual - wa->qual;
+ 	return snr_b - snr_a;
+ #undef MIN
+-#undef IS_5GHZ
+ }
+ 
+ 
+@@ -1670,15 +1668,15 @@ static void dump_scan_res(struct wpa_sca
+ 	for (i = 0; i < scan_res->num; i++) {
+ 		struct wpa_scan_res *r = scan_res->res[i];
+ 		u8 *pos;
+-		if ((r->flags & (WPA_SCAN_LEVEL_DBM | WPA_SCAN_NOISE_INVALID))
+-		    == WPA_SCAN_LEVEL_DBM) {
++		if (r->flags & WPA_SCAN_LEVEL_DBM) {
+ 			int snr = r->level - r->noise;
++			int noise_valid = !(r->flags & WPA_SCAN_NOISE_INVALID);
++
+ 			wpa_printf(MSG_EXCESSIVE, MACSTR " freq=%d qual=%d "
+-				   "noise=%d level=%d snr=%d%s flags=0x%x "
+-				   "age=%u",
++				   "noise=%d%s level=%d snr=%d%s flags=0x%x age=%u",
+ 				   MAC2STR(r->bssid), r->freq, r->qual,
+-				   r->noise, r->level, snr,
+-				   snr >= GREAT_SNR ? "*" : "", r->flags,
++				   r->noise, noise_valid ? "" : "~", r->level,
++				   snr, snr >= GREAT_SNR ? "*" : "", r->flags,
+ 				   r->age);
+ 		} else {
+ 			wpa_printf(MSG_EXCESSIVE, MACSTR " freq=%d qual=%d "
+@@ -1751,6 +1749,14 @@ static void filter_scan_res(struct wpa_s
+ }
+ 
+ 
++/*
++ * Noise floor values to use when we have signal strength
++ * measurements, but no noise floor measurments. These values were
++ * measured in an office environment with many APs.
++ */
++#define DEFAULT_NOISE_FLOOR_2GHZ (-89)
++#define DEFAULT_NOISE_FLOOR_5GHZ (-92)
++
+ /**
+  * wpa_supplicant_get_scan_results - Get scan results
+  * @wpa_s: Pointer to wpa_supplicant data
+@@ -1784,6 +1790,17 @@ wpa_supplicant_get_scan_results(struct w
+ 	}
+ 	filter_scan_res(wpa_s, scan_res);
+ 
++	for (i = 0; i < scan_res->num; i++) {
++		struct wpa_scan_res *scan_res_item = scan_res->res[i];
++
++		if (scan_res_item->flags & WPA_SCAN_NOISE_INVALID) {
++			scan_res_item->noise =
++				IS_5GHZ(scan_res_item->freq) ?
++				DEFAULT_NOISE_FLOOR_5GHZ :
++				DEFAULT_NOISE_FLOOR_2GHZ;
++		}
++	}
++
+ #ifdef CONFIG_WPS
+ 	if (wpas_wps_searching(wpa_s)) {
+ 		wpa_dbg(wpa_s, MSG_DEBUG, "WPS: Order scan results with WPS "
diff -Nru wpa-2.3/debian/patches/select-AP-based-on-estimated-maximum-throughput.patch wpa-2.3/debian/patches/select-AP-based-on-estimated-maximum-throughput.patch
--- wpa-2.3/debian/patches/select-AP-based-on-estimated-maximum-throughput.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/select-AP-based-on-estimated-maximum-throughput.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,366 @@
+From a1b790eb9d7514d1a6e0582a07f695a1564caa59 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <j...@w1.fi>
+Date: Sat, 21 Feb 2015 22:53:42 +0200
+Subject: Select AP based on estimated maximum throughput
+
+This modifies the BSS selection routines to calculate SNR and estimated
+throughput for each scan result and then use the estimated throughput as
+a criteria for sorting the results. This extends the earlier design by
+taking into account higher throughput rates if both the AP and local
+device supports HT20, HT40, or VHT80. In addition, the maximum rate is
+restricted based on SNR.
+
+In practice, this gives significantly higher probability of selecting
+HT/VHT APs when there are multiple BSSes in the same ESS and SNR is not
+low enough to prevent higher MCS use.
+
+Signed-off-by: Jouni Malinen <j...@w1.fi>
+---
+ src/drivers/driver.h              |   5 +
+ wpa_supplicant/scan.c             | 219 +++++++++++++++++++++++++++++++++-----
+ wpa_supplicant/wpa_supplicant.c   |  17 +++
+ wpa_supplicant/wpa_supplicant_i.h |   6 ++
+ 4 files changed, 223 insertions(+), 24 deletions(-)
+
+--- a/src/drivers/driver.h
++++ b/src/drivers/driver.h
+@@ -202,6 +202,9 @@ struct hostapd_hw_modes {
+  * @tsf: Timestamp
+  * @age: Age of the information in milliseconds (i.e., how many milliseconds
+  * ago the last Beacon or Probe Response frame was received)
++ * @est_throughput: Estimated throughput in kbps (this is calculated during
++ * scan result processing if left zero by the driver wrapper)
++ * @snr: Signal-to-noise ratio in dB (calculated during scan result processing)
+  * @ie_len: length of the following IE field in octets
+  * @beacon_ie_len: length of the following Beacon IE field in octets
+  *
+@@ -225,6 +228,8 @@ struct wpa_scan_res {
+ 	int level;
+ 	u64 tsf;
+ 	unsigned int age;
++	unsigned int est_throughput;
++	int snr;
+ 	size_t ie_len;
+ 	size_t beacon_ie_len;
+ 	/*
+--- a/wpa_supplicant/scan.c
++++ b/wpa_supplicant/scan.c
+@@ -1554,8 +1554,8 @@ static int wpa_scan_result_compar(const
+ 	struct wpa_scan_res **_wb = (void *) b;
+ 	struct wpa_scan_res *wa = *_wa;
+ 	struct wpa_scan_res *wb = *_wb;
+-	int wpa_a, wpa_b, maxrate_a, maxrate_b;
+-	int snr_a, snr_b;
++	int wpa_a, wpa_b;
++	int snr_a, snr_b, snr_a_full, snr_b_full;
+ 
+ 	/* WPA/WPA2 support preferred */
+ 	wpa_a = wpa_scan_get_vendor_ie(wa, WPA_IE_VENDOR_TYPE) != NULL ||
+@@ -1577,22 +1577,22 @@ static int wpa_scan_result_compar(const
+ 		return -1;
+ 
+ 	if (wa->flags & wb->flags & WPA_SCAN_LEVEL_DBM) {
+-		snr_a = MIN(wa->level - wa->noise, GREAT_SNR);
+-		snr_b = MIN(wb->level - wb->noise, GREAT_SNR);
++		snr_a_full = wa->snr;
++		snr_a = MIN(wa->snr, GREAT_SNR);
++		snr_b_full = wb->snr;
++		snr_b = MIN(wa->snr, GREAT_SNR);
+ 	} else {
+ 		/* Level is not in dBm, so we can't calculate
+ 		 * SNR. Just use raw level (units unknown). */
+-		snr_a = wa->level;
+-		snr_b = wb->level;
++		snr_a = snr_a_full = wa->level;
++		snr_b = snr_b_full = wb->level;
+ 	}
+ 
+ 	/* if SNR is close, decide by max rate or frequency band */
+ 	if ((snr_a && snr_b && abs(snr_b - snr_a) < 5) ||
+ 	    (wa->qual && wb->qual && abs(wb->qual - wa->qual) < 10)) {
+-		maxrate_a = wpa_scan_get_max_rate(wa);
+-		maxrate_b = wpa_scan_get_max_rate(wb);
+-		if (maxrate_a != maxrate_b)
+-			return maxrate_b - maxrate_a;
++		if (wa->est_throughput != wb->est_throughput)
++			return wb->est_throughput - wa->est_throughput;
+ 		if (IS_5GHZ(wa->freq) ^ IS_5GHZ(wb->freq))
+ 			return IS_5GHZ(wa->freq) ? -1 : 1;
+ 	}
+@@ -1600,9 +1600,9 @@ static int wpa_scan_result_compar(const
+ 	/* all things being equal, use SNR; if SNRs are
+ 	 * identical, use quality values since some drivers may only report
+ 	 * that value and leave the signal level zero */
+-	if (snr_b == snr_a)
++	if (snr_b_full == snr_a_full)
+ 		return wb->qual - wa->qual;
+-	return snr_b - snr_a;
++	return snr_b_full - snr_a_full;
+ #undef MIN
+ }
+ 
+@@ -1669,20 +1669,21 @@ static void dump_scan_res(struct wpa_sca
+ 		struct wpa_scan_res *r = scan_res->res[i];
+ 		u8 *pos;
+ 		if (r->flags & WPA_SCAN_LEVEL_DBM) {
+-			int snr = r->level - r->noise;
+ 			int noise_valid = !(r->flags & WPA_SCAN_NOISE_INVALID);
+ 
+ 			wpa_printf(MSG_EXCESSIVE, MACSTR " freq=%d qual=%d "
+-				   "noise=%d%s level=%d snr=%d%s flags=0x%x age=%u",
++				   "noise=%d%s level=%d snr=%d%s flags=0x%x age=%u est=%u",
+ 				   MAC2STR(r->bssid), r->freq, r->qual,
+ 				   r->noise, noise_valid ? "" : "~", r->level,
+-				   snr, snr >= GREAT_SNR ? "*" : "", r->flags,
+-				   r->age);
++				   r->snr, r->snr >= GREAT_SNR ? "*" : "",
++				   r->flags,
++				   r->age, r->est_throughput);
+ 		} else {
+ 			wpa_printf(MSG_EXCESSIVE, MACSTR " freq=%d qual=%d "
+-				   "noise=%d level=%d flags=0x%x age=%u",
++				   "noise=%d level=%d flags=0x%x age=%u est=%u",
+ 				   MAC2STR(r->bssid), r->freq, r->qual,
+-				   r->noise, r->level, r->flags, r->age);
++				   r->noise, r->level, r->flags, r->age,
++				   r->est_throughput);
+ 		}
+ 		pos = (u8 *) (r + 1);
+ 		if (r->ie_len)
+@@ -1757,6 +1758,180 @@ static void filter_scan_res(struct wpa_s
+ #define DEFAULT_NOISE_FLOOR_2GHZ (-89)
+ #define DEFAULT_NOISE_FLOOR_5GHZ (-92)
+ 
++static void scan_snr(struct wpa_scan_res *res)
++{
++	if (res->flags & WPA_SCAN_NOISE_INVALID) {
++		res->noise = IS_5GHZ(res->freq) ?
++			DEFAULT_NOISE_FLOOR_5GHZ :
++			DEFAULT_NOISE_FLOOR_2GHZ;
++	}
++
++	if (res->flags & WPA_SCAN_LEVEL_DBM) {
++		res->snr = res->level - res->noise;
++	} else {
++		/* Level is not in dBm, so we can't calculate
++		 * SNR. Just use raw level (units unknown). */
++		res->snr = res->level;
++	}
++}
++
++
++static unsigned int max_ht20_rate(int snr)
++{
++	if (snr < 6)
++		return 6500; /* HT20 MCS0 */
++	if (snr < 8)
++		return 13000; /* HT20 MCS1 */
++	if (snr < 13)
++		return 19500; /* HT20 MCS2 */
++	if (snr < 17)
++		return 26000; /* HT20 MCS3 */
++	if (snr < 20)
++		return 39000; /* HT20 MCS4 */
++	if (snr < 23)
++		return 52000; /* HT20 MCS5 */
++	if (snr < 24)
++		return 58500; /* HT20 MCS6 */
++	return 65000; /* HT20 MCS7 */
++}
++
++
++static unsigned int max_ht40_rate(int snr)
++{
++	if (snr < 3)
++		return 13500; /* HT40 MCS0 */
++	if (snr < 6)
++		return 27000; /* HT40 MCS1 */
++	if (snr < 10)
++		return 40500; /* HT40 MCS2 */
++	if (snr < 15)
++		return 54000; /* HT40 MCS3 */
++	if (snr < 17)
++		return 81000; /* HT40 MCS4 */
++	if (snr < 22)
++		return 108000; /* HT40 MCS5 */
++	if (snr < 22)
++		return 121500; /* HT40 MCS6 */
++	return 135000; /* HT40 MCS7 */
++}
++
++
++static unsigned int max_vht80_rate(int snr)
++{
++	if (snr < 1)
++		return 0;
++	if (snr < 2)
++		return 29300; /* VHT80 MCS0 */
++	if (snr < 5)
++		return 58500; /* VHT80 MCS1 */
++	if (snr < 9)
++		return 87800; /* VHT80 MCS2 */
++	if (snr < 11)
++		return 117000; /* VHT80 MCS3 */
++	if (snr < 15)
++		return 175500; /* VHT80 MCS4 */
++	if (snr < 16)
++		return 234000; /* VHT80 MCS5 */
++	if (snr < 18)
++		return 263300; /* VHT80 MCS6 */
++	if (snr < 20)
++		return 292500; /* VHT80 MCS7 */
++	if (snr < 22)
++		return 351000; /* VHT80 MCS8 */
++	return 390000; /* VHT80 MCS9 */
++}
++
++
++static void scan_est_throughput(struct wpa_supplicant *wpa_s,
++				struct wpa_scan_res *res)
++{
++	enum local_hw_capab capab = wpa_s->hw_capab;
++	int rate; /* max legacy rate in 500 kb/s units */
++	const u8 *ie;
++	unsigned int est, tmp;
++	int snr = res->snr;
++
++	if (res->est_throughput)
++		return;
++
++	/* Get maximum legacy rate */
++	rate = wpa_scan_get_max_rate(res);
++
++	/* Limit based on estimated SNR */
++	if (rate > 1 * 2 && snr < 1)
++		rate = 1 * 2;
++	else if (rate > 2 * 2 && snr < 4)
++		rate = 2 * 2;
++	else if (rate > 6 * 2 && snr < 5)
++		rate = 6 * 2;
++	else if (rate > 9 * 2 && snr < 6)
++		rate = 9 * 2;
++	else if (rate > 12 * 2 && snr < 7)
++		rate = 12 * 2;
++	else if (rate > 18 * 2 && snr < 10)
++		rate = 18 * 2;
++	else if (rate > 24 * 2 && snr < 11)
++		rate = 24 * 2;
++	else if (rate > 36 * 2 && snr < 15)
++		rate = 36 * 2;
++	else if (rate > 48 * 2 && snr < 19)
++		rate = 48 * 2;
++	else if (rate > 54 * 2 && snr < 21)
++		rate = 54 * 2;
++	est = rate * 500;
++
++	if (capab == CAPAB_HT || capab == CAPAB_HT40 || capab == CAPAB_VHT) {
++		ie = wpa_scan_get_ie(res, WLAN_EID_HT_CAP);
++		if (ie) {
++			tmp = max_ht20_rate(snr);
++			if (tmp > est)
++				est = tmp;
++		}
++	}
++
++	if (capab == CAPAB_HT40 || capab == CAPAB_VHT) {
++		ie = wpa_scan_get_ie(res, WLAN_EID_HT_OPERATION);
++		if (ie && ie[1] >= 2 &&
++		    (ie[3] & HT_INFO_HT_PARAM_SECONDARY_CHNL_OFF_MASK)) {
++			tmp = max_ht40_rate(snr);
++			if (tmp > est)
++				est = tmp;
++		}
++	}
++
++	if (capab == CAPAB_VHT) {
++		/* Use +1 to assume VHT is always faster than HT */
++		ie = wpa_scan_get_ie(res, WLAN_EID_VHT_CAP);
++		if (ie) {
++			tmp = max_ht20_rate(snr) + 1;
++			if (tmp > est)
++				est = tmp;
++
++			ie = wpa_scan_get_ie(res, WLAN_EID_HT_OPERATION);
++			if (ie && ie[1] >= 2 &&
++			    (ie[3] &
++			     HT_INFO_HT_PARAM_SECONDARY_CHNL_OFF_MASK)) {
++				tmp = max_ht40_rate(snr) + 1;
++				if (tmp > est)
++					est = tmp;
++			}
++
++			ie = wpa_scan_get_ie(res, WLAN_EID_VHT_OPERATION);
++			if (ie && ie[1] >= 1 &&
++			    (ie[2] & VHT_OPMODE_CHANNEL_WIDTH_MASK)) {
++				tmp = max_vht80_rate(snr) + 1;
++				if (tmp > est)
++					est = tmp;
++			}
++		}
++	}
++
++	/* TODO: channel utilization and AP load (e.g., from AP Beacon) */
++
++	res->est_throughput = est;
++}
++
++
+ /**
+  * wpa_supplicant_get_scan_results - Get scan results
+  * @wpa_s: Pointer to wpa_supplicant data
+@@ -1793,12 +1968,8 @@ wpa_supplicant_get_scan_results(struct w
+ 	for (i = 0; i < scan_res->num; i++) {
+ 		struct wpa_scan_res *scan_res_item = scan_res->res[i];
+ 
+-		if (scan_res_item->flags & WPA_SCAN_NOISE_INVALID) {
+-			scan_res_item->noise =
+-				IS_5GHZ(scan_res_item->freq) ?
+-				DEFAULT_NOISE_FLOOR_5GHZ :
+-				DEFAULT_NOISE_FLOOR_2GHZ;
+-		}
++		scan_snr(scan_res_item);
++		scan_est_throughput(wpa_s, scan_res_item);
+ 	}
+ 
+ #ifdef CONFIG_WPS
+--- a/wpa_supplicant/wpa_supplicant.c
++++ b/wpa_supplicant/wpa_supplicant.c
+@@ -3759,6 +3759,23 @@ static int wpa_supplicant_init_iface(str
+ 	wpa_s->hw.modes = wpa_drv_get_hw_feature_data(wpa_s,
+ 						      &wpa_s->hw.num_modes,
+ 						      &wpa_s->hw.flags);
++	if (wpa_s->hw.modes) {
++		u16 i;
++
++		for (i = 0; i < wpa_s->hw.num_modes; i++) {
++			if (wpa_s->hw.modes[i].vht_capab) {
++				wpa_s->hw_capab = CAPAB_VHT;
++				break;
++			}
++
++			if (wpa_s->hw.modes[i].ht_capab &
++			    HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET)
++				wpa_s->hw_capab = CAPAB_HT40;
++			else if (wpa_s->hw.modes[i].ht_capab &&
++				 wpa_s->hw_capab == CAPAB_NO_HT_VHT)
++				wpa_s->hw_capab = CAPAB_HT;
++		}
++	}
+ 
+ 	if (wpa_drv_get_capa(wpa_s, &capa) == 0) {
+ 		wpa_s->drv_capa_known = 1;
+--- a/wpa_supplicant/wpa_supplicant_i.h
++++ b/wpa_supplicant/wpa_supplicant_i.h
+@@ -825,6 +825,12 @@ struct wpa_supplicant {
+ 		u16 num_modes;
+ 		u16 flags;
+ 	} hw;
++	enum local_hw_capab {
++		CAPAB_NO_HT_VHT,
++		CAPAB_HT,
++		CAPAB_HT40,
++		CAPAB_VHT,
++	} hw_capab;
+ #ifdef CONFIG_MACSEC
+ 	struct ieee802_1x_kay *kay;
+ #endif /* CONFIG_MACSEC */
diff -Nru wpa-2.3/debian/patches/series wpa-2.3/debian/patches/series
--- wpa-2.3/debian/patches/series	2015-11-07 16:07:28.000000000 +0100
+++ wpa-2.3/debian/patches/series	2016-07-21 09:19:32.000000000 +0200
@@ -19,3 +19,8 @@
 CVE-2015-5314.patch
 CVE-2015-5315.patch
 CVE-2015-5316.patch
+2016-1/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
+2016-1/0002-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
+2016-1/0003-Remove-newlines-from-wpa_supplicant-config-network-o.patch
+2016-1/0004-Reject-SET_CRED-commands-with-newline-characters-in-.patch
+2016-1/0005-Reject-SET-commands-with-newline-characters-in-the-s.patch
diff -Nru wpa-2.3/debian/patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch wpa-2.3/debian/patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch
--- wpa-2.3/debian/patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch	1970-01-01 01:00:00.000000000 +0100
+++ wpa-2.3/debian/patches/wpa_supplicant-Fix-a-typo-in-wpa_scan_result_compar.patch	2016-07-21 08:49:03.000000000 +0200
@@ -0,0 +1,26 @@
+From aa517ae22784aff08d3d9e38ad101b4b5c9828fb Mon Sep 17 00:00:00 2001
+From: "Hahn, Maital" <mait...@ti.com>
+Date: Wed, 8 Jul 2015 13:13:11 +0000
+Subject: wpa_supplicant: Fix a typo in wpa_scan_result_compar()
+
+A typo in wpa_scan_result_compar() caused wrong scan results sorting
+(and wrong roaming decision). This fixes a copy-paste regression
+introduced by commit a1b790eb9d7514d1a6e0582a07f695a1564caa59 ('Select
+AP based on estimated maximum throughput').
+
+Signed-off-by: Maital Hahn <mait...@ti.com>
+---
+ wpa_supplicant/scan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/wpa_supplicant/scan.c
++++ b/wpa_supplicant/scan.c
+@@ -1580,7 +1580,7 @@ static int wpa_scan_result_compar(const
+ 		snr_a_full = wa->snr;
+ 		snr_a = MIN(wa->snr, GREAT_SNR);
+ 		snr_b_full = wb->snr;
+-		snr_b = MIN(wa->snr, GREAT_SNR);
++		snr_b = MIN(wb->snr, GREAT_SNR);
+ 	} else {
+ 		/* Level is not in dBm, so we can't calculate
+ 		 * SNR. Just use raw level (units unknown). */

--- End Message ---
--- Begin Message ---
Version: 8.6

The updates referred to in each of these bugs were included in today's
stable point release.

Regards,

Adam

--- End Message ---

Reply via email to