--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: jessie-pu: package wpa/2.3-1+deb8u4
- From: Andrew Shadura <andrewsh@debian.org>
- Date: Thu, 21 Jul 2016 10:51:36 +0200
- Message-id: <146909109648.30717.2945556256478801935.reportbug@nuevo>
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian.org@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 <carnil@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 <andrewsh@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 <jouni@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 <jouni@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 <jouni@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 <jouni@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 <jouni@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 <jouni@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 <pstew@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 <pstew@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 <jouni@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 <jouni@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 <jouni@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 <jouni@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.l-h@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.l-h@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.l-h@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.l-h@gmx.de>
+---
+submitted upstream
+ Message-Id: <201402202119.15847.s.L-H@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 <quiche@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 <quiche@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" <maitalm@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 <maitalm@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 ---