Commit d8639f35 authored by Natanael Copa's avatar Natanael Copa

main/hostapd: various security fixes

CVE-2015-4141
CVE-2015-4142
CVE-2015-4143
CVE-2015-4144
CVE-2015-4145
CVE-2015-4146

fixes #4335
fixes #4270
parent 62ecb530
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(+)
diff --git a/src/eap_peer/eap_pwd.c b/src/eap_peer/eap_pwd.c
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,
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) ||
@@ -554,6 +571,18 @@ eap_pwd_perform_confirm_exchange(struct eap_sm *sm, struct eap_pwd_data *data,
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
--
1.9.1
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(+)
diff --git a/src/eap_server/eap_server_pwd.c b/src/eap_server/eap_server_pwd.c
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,
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) ||
@@ -774,6 +786,13 @@ eap_pwd_process_confirm_resp(struct eap_sm *sm, struct eap_pwd_data *data,
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;
--
1.9.1
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(+)
diff --git a/src/eap_peer/eap_pwd.c b/src/eap_peer/eap_pwd.c
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,
* 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 "
--
1.9.1
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(+)
diff --git a/src/eap_server/eap_server_pwd.c b/src/eap_server/eap_server_pwd.c
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,
* 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 "
--
1.9.1
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(+)
diff --git a/src/eap_peer/eap_pwd.c b/src/eap_peer/eap_pwd.c
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,
/*
* 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,
--
1.9.1
......@@ -10,7 +10,21 @@ depends=
makedepends="openssl-dev libnl3-dev linux-headers"
install=
subpackages="$pkgname-doc"
patches="CVE-2012-4445.patch musl-fix-types.patch"
patches="
musl-fix-types.patch
CVE-2012-4445.patch
0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
CVE-2015-1863.patch
CVE-2015-4141.patch
CVE-2015-4142.patch
"
source="http://hostap.epitest.fi/releases/$pkgname-$pkgver.tar.gz
$patches
$pkgname.initd
......@@ -79,17 +93,41 @@ package() {
}
md5sums="04578f3f2c3eb1bec1adf30473813912 hostapd-2.4.tar.gz
0d01d4641e0c33f79c1f4372613655bf CVE-2012-4445.patch
7568486221987c93041b4877eced7317 musl-fix-types.patch
0d01d4641e0c33f79c1f4372613655bf CVE-2012-4445.patch
87d611a9b704402f66fa59ba1458928d 0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
bafcec421e4f5c6a8383893d029a79e5 0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
fa2aed3cf49f7e6c7b17bf9db9a001f5 0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
de0fca4d74a1883d15ef5754f13a5226 0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
9d854969af23b207f9f3dff38ef78770 0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
8e8c34267fefcc4142ee142e5515b5df CVE-2015-1863.patch
222ec96a8dc73c41608cc463beac3966 CVE-2015-4141.patch
d3688697f81ca1e684a79dfa3682a111 CVE-2015-4142.patch
29b561d4ee34dc22a8a0ae0bf1db5c45 hostapd.initd
c91382209042defa04e79d0ae841a29e hostapd.confd"
sha256sums="6fe0eb6bd1c9cbd24952ece8586b6f7bd14ab358edfda99794e79b9b9dbd657f hostapd-2.4.tar.gz
06dc7df2159fb0604191f66d35164caa5927963eebe77b5f2c389bd7590e2a49 CVE-2012-4445.patch
f296013d432740478f24de7214d07ff897e6e38cbfd01a73a3158014f94fd771 musl-fix-types.patch
06dc7df2159fb0604191f66d35164caa5927963eebe77b5f2c389bd7590e2a49 CVE-2012-4445.patch
a204bc37f52e5346780a306c01706689eb46263dedcdcb1eb2f4c0b291a0db93 0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
298fc3b89f987922fb2600d0c95e8c868d6da30d24643748afd47bcd30da7b44 0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
2fd42fb53be793c54343aa18a84afebe4603aa6ce8b6969ad6b3a8d327c6b142 0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
c28ca6303a562809dfd1812f9b918808b3b0f0c52cc43070fd1777e1cfc88f18 0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
04ef66fbd5b2167274cd7123d7f7252963b9a9c1ec2f5edf6558a6ad92d47689 0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
a3abf75801f02199ff48c316a7b6598860e6ca20ce2fe79b0bec873905e5c8a4 CVE-2015-1863.patch
eb63d845fdc38b6310c527ad1705b6fe3b74f90e263188da2aca97468cc55142 CVE-2015-4141.patch
cc6c488afab4ccfdaedd9e224989b5fe713d6b0415ea94579190bd8ba60c9be5 CVE-2015-4142.patch
cae79127d088c047c1460d5b63eb67da1a830eb725a8c95e50070e516ad02800 hostapd.initd
6c14e88b14bb9a93d2dca69239d829f435e93180e621319aeed0f3987290dfba hostapd.confd"
sha512sums="37e648fe9cce92923ab1d1e23a4267e274c988785d7be5610f1affca425ffa86b438de81e37446926a0f9158d6b67ee83e6396c3f81d571545c973dddbf1ffe3 hostapd-2.4.tar.gz
619acce84516dead1e03e5da71657ea4c4b6f3ca8271574409773aeb316cbddc88095b50320804f457f001f4f3fe83053e660c008d8409f59bb4d3bfe058b601 CVE-2012-4445.patch
6ccdca29bc3a6b87d6e3f581c4f4725f0684bb88f39d46f875e9bdb0c41ee5b8be3b7908084c6631bffddece82cb2f2222e159d842944b6f2b7b639ef2de609c musl-fix-types.patch
619acce84516dead1e03e5da71657ea4c4b6f3ca8271574409773aeb316cbddc88095b50320804f457f001f4f3fe83053e660c008d8409f59bb4d3bfe058b601 CVE-2012-4445.patch
9440f8d9d18d20b95d236c1a4467d86dfbbc17d8f26b0caa48d6737c6231d1ff14793c6fc8a1e4508f3ad38c9a5d710fd49b85c7de16634dbe6685af05f44f7c 0001-EAP-pwd-peer-Fix-payload-length-validation-for-Commi.patch
0887017bfdb4632baa49bb849b732eed7eec9a498247fdd5ef8448e4a6df10380c06d68fa706e0b2624c04eb6f5a327cdb71c5c71c3476dc383f889ee7372702 0002-EAP-pwd-server-Fix-payload-length-validation-for-Com.patch
341901aa94c44ae725b6d4dddac2a52b6457234189554fc282c9cf5fa0254125d7323553a7b8118f9a3e2020f039267ed4c912f84ac6f2cb12670b40c28ac652 0003-EAP-pwd-peer-Fix-Total-Length-parsing-for-fragment-r.patch
b752f91c3d6dcf0784d9cb20a0c7f8de6c837c38ff62cf77b136d9b818890b13f55eeed1d6097f244181b480be953e1bdfb5651116dc5d62a2d02c018e19042a 0004-EAP-pwd-server-Fix-Total-Length-parsing-for-fragment.patch
07a21f0cc7d00e17bed8ef5ced36159020a410a4606aa0ca24e47223835ab0cc5fbeed3075c4f17d2ce1aee437eedf9fea8f4b95252b2fa255d54a195637cb6f 0005-EAP-pwd-peer-Fix-asymmetric-fragmentation-behavior.patch
61f90d06bd42fb7ea17ba147db861303f5b1fdce2cda35492cec578214da5ea5d654a1df99dee4d4a0c07ef3e8b3bfb65ab4b98eff21c2013adf536766136ce1 CVE-2015-1863.patch
4633a96a91e151407e4c62b74b4e78d37e4fba586278c6ae4340ce149bee0c644a4d62675256839c3130374a4dc7531beaeed8282946e7dcd3faf1ed74bf99be CVE-2015-4141.patch
dc561d90f3f329ebb201abbb53eea161603fb2abba6b2fc5c79298d97c84f2d65d401608cd7bb2fb82abf909661c56699bf4bcbf902f6f8c7d5b1853b0277353 CVE-2015-4142.patch
b54b7c6aa17e5cb86a9b354a516eb2dbefb544df18471339c61d82776de447011a2ac290bea1e6c8beae4b6cebefafb8174683ea42fb773e9e8fe6c679f33ba3 hostapd.initd
0882263bbd7c0b05bf51f51d66e11a23a0b8ca7da2a3b8a30166d2c5f044c0c134e6bccb1d02c9e81819ca8fb0c0fb55c7121a08fe7233ccaa73ff8ab9a238fe hostapd.confd"
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(+)
diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
index f584fae..a45fe73 100644
--- a/src/p2p/p2p.c
+++ b/src/p2p/p2p.c
@@ -778,6 +778,7 @@ int p2p_add_device(struct p2p_data *p2p, const u8 *addr, int freq,
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)) {
--
1.9.1
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(+)
diff --git a/src/wps/httpread.c b/src/wps/httpread.c
index 2f08f37..d2855e3 100644
--- a/src/wps/httpread.c
+++ b/src/wps/httpread.c
@@ -533,6 +533,13 @@ static void httpread_read_handler(int sd, void *eloop_ctx, void *sock_ctx)
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
*/
--
1.9.1
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(+)
diff --git a/src/ap/wmm.c b/src/ap/wmm.c
index 6d4177c..314e244 100644
--- a/src/ap/wmm.c
+++ b/src/ap/wmm.c
@@ -274,6 +274,9 @@ void hostapd_wmm_action(struct hostapd_data *hapd,
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,
--
1.9.1
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment