linux-stable.git/net/wireless, branch v3.12.52

cfg80211: wext: clear sinfo struct before calling driver

2015-06-23T12:55:14+00:00

commit 9c5a18a31b321f120efda412281bb9f610f84aa0 upstream.

Until recently, mac80211 overwrote all the statistics it could
provide when getting called, but it now relies on the struct
having been zeroed by the caller. This was always the case in
nl80211, but wext used a static struct which could even cause
values from one device leak to another.

Using a static struct is OK (as even documented in a comment)
since the whole usage of this function and its return value is
always locked under RTNL. Not clearing the struct for calling
the driver has always been wrong though, since drivers were
free to only fill values they could report, so calling this
for one device and then for another would always have leaked
values from one to the other.

Fix this by initializing the structure in question before the
driver method call.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691

Reported-by: Gerrit Renker 
Reported-by: Alexander Kaltsas 
Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

nl80211: ignore HT/VHT capabilities without QoS/WMM

2015-04-09T12:14:06+00:00

commit 496fcc294daab18799e190c0264863d653588d1f upstream.

As HT/VHT depend heavily on QoS/WMM, it's not a good idea to
let userspace add clients that have HT/VHT but not QoS/WMM.
Since it does so in certain cases we've observed (client is
using HT IEs but not QoS/WMM) just ignore the HT/VHT info at
this point and don't pass it down to the drivers which might
unconditionally use it.

Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers

2015-04-09T12:13:39+00:00

commit 08f6f147773b23b765b94633a8eaa82e7defcf4c upstream.

The VHT supported channel width field is a two bit integer, not a
bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and
ended up rejecting 160 MHz channel width if the driver indicated support
for both 160 and 80+80 MHz channels.

Cc: stable@vger.kernel.org (3.16+)
Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration")
       (however, no real drivers had 160 MHz support it until 3.16)
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 

Signed-off-by: Jiri Slaby

nl80211: fix per-station group key get/del and memory leak

2015-02-08T19:02:00+00:00

commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream.

In case userspace attempts to obtain key information for or delete a
unicast key, this is currently erroneously rejected unless the driver
sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it
was never noticed.

Fix that, and while at it fix a potential memory leak: the error path
in the get_key() function was placed after allocating a message but
didn't free it - move it to a better place. Luckily admin permissions
are needed to call this operation.

Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

cfg80211: avoid mem leak on driver hint set

2015-01-26T13:39:28+00:00

commit 34f05f543f02350e920bddb7660ffdd4697aaf60 upstream.

In the already-set and intersect case of a driver-hint, the previous
wiphy regdomain was not freed before being reset with a copy of the
cfg80211 regdomain.

[js: backport to 3.12]

Signed-off-by: Arik Nemtsov 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

nl80211: clear skb cb before passing to netlink

2014-10-13T13:41:36+00:00

commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream.

In testmode and vendor command reply/event SKBs we use the
skb cb data to store nl80211 parameters between allocation
and sending. This causes the code for CONFIG_NETLINK_MMAP
to get confused, because it takes ownership of the skb cb
data when the SKB is handed off to netlink, and it doesn't
explicitly clear it.

Clear the skb cb explicitly when we're done and before it
gets passed to netlink to avoid this issue.

Reported-by: Assaf Azulay 
Reported-by: David Spinadel 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

cfg80211: fix mic_failure tracing

2014-08-19T12:23:34+00:00

commit 8c26d458394be44e135d1c6bd4557e1c4e1a0535 upstream.

tsc can be NULL (mac80211 currently always passes NULL),
resulting in NULL-dereference. check before copying it.

Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

cfg80211: free sme on connection failures

2014-06-06T09:40:22+00:00

commit c1fbb258846dfc425507a093922d2d001e54c3ea upstream.

cfg80211 is notified about connection failures by
__cfg80211_connect_result() call. However, this
function currently does not free cfg80211 sme.

This results in hanging connection attempts in some cases

e.g. when mac80211 authentication attempt is denied,
we have this function call:
ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() ->
cfg80211_process_auth() -> cfg80211_sme_rx_auth() ->
__cfg80211_connect_result()

but cfg80211_sme_free() is never get called.

Fixes: ceca7b712 ("cfg80211: separate internal SME implementation")
Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

nl80211: Reset split_start when netlink skb is exhausted

2014-02-22T21:32:25+00:00

commit f12cb2893069495726c21a4b0178705dacfecfe0 upstream.

When the netlink skb is exhausted split_start is left set. In the
subsequent retry, with a larger buffer, the dump is continued from the
failing point instead of from the beginning.

This was causing my rt28xx based USB dongle to now show up when
running "iw list" with an old iw version without split dump support.

Fixes: 3713b4e364ef ("nl80211: allow splitting wiphy information in dumps")
Signed-off-by: Pontus Fuchs 
[avoid the entire workaround when state->split is set]
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

radiotap: fix bitmap-end-finding buffer overrun

2014-01-09T20:25:13+00:00

commit bd02cd2549cfcdfc57cb5ce57ffc3feb94f70575 upstream.

Evan Huus found (by fuzzing in wireshark) that the radiotap
iterator code can access beyond the length of the buffer if
the first bitmap claims an extension but then there's no
data at all. Fix this.

Reported-by: Evan Huus 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman