linux-stable.git/net/wireless, branch v4.1.26

nl80211: check netlink protocol in socket release notification

2016-05-08T12:08:59+00:00

[ Upstream commit 8f815cdde3e550e10c2736990d791f60c2ce43eb ]

A non-privileged user can create a netlink socket with the same port_id as
used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
process) with a different protocol number.

Closing this socket will then lead to the notification going to nl80211's
socket release notification handler, and possibly cause an action such as
removing a virtual interface.

Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
Since generic netlink has no notifier chain of its own, we can't fix the
problem more generically.

Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Ivanov 
[rewrite commit message]
Signed-off-by: Johannes Berg 

Signed-off-by: Sasha Levin

cfg80211/wext: fix message ordering

2016-03-18T03:13:32+00:00

[ Upstream commit cb150b9d23be6ee7f3a0fff29784f1c5b5ac514d ]

Since cfg80211 frequently takes actions from its netdev notifier
call, wireless extensions messages could still be ordered badly
since the wext netdev notifier, since wext is built into the
kernel, runs before the cfg80211 netdev notifier. For example,
the following can happen:

5: wlan1:  mtu 1500 qdisc mq state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: 
    link/ether

when setting the interface down causes the wext message.

To also fix this, export the wireless_nlevent_flush() function
and also call it from the cfg80211 notifier.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wext: fix message delay/ordering

2016-03-18T03:13:29+00:00

[ Upstream commit 8bf862739a7786ae72409220914df960a0aa80d8 ]

Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been connected and disconnection while it was deleted
caused a wext message.

For its netlink messages, wext uses RTM_NEWLINK, but the message is
without all the regular rtnetlink attributes, so "ip monitor link"
prints just rudimentary information:

5: wlan1:  mtu 1500 qdisc mq state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
Deleted 5: wlan1:  mtu 1500 qdisc noop state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: 
    link/ether
(from my hwsim reproduction)

This can cause userspace to get confused since it doesn't expect an
RTM_NEWLINK message after RTM_DELLINK.

The reason for this is that wext schedules a worker to send out the
messages, and the scheduling delay can cause the messages to get out
to userspace in different order.

To fix this, have wext register a netdevice notifier and flush out
any pending messages when netdevice state changes. This fixes any
ordering whenever the original message wasn't sent by a notifier
itself.

Cc: stable@vger.kernel.org
Reported-by: Beniamino Galvani 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

nl80211: Fix potential memory leak from parse_acl_data

2015-12-09T19:03:19+00:00

commit 4baf6bea37247e59f1971e8009d13aeda95edba2 upstream.

If parse_acl_data succeeds but the subsequent parsing of smps
attributes fails, there will be a memory leak due to early returns.
Fix that by moving the ACL parsing later.

Fixes: 18998c381b19b ("cfg80211: allow requesting SMPS mode on ap start")
Signed-off-by: Ola Olsson 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: ignore netif running state when changing iftype

2015-08-03T16:29:16+00:00

commit 6cbfb1bb66e4e85da5db78e8ff429a85bd84ce64 upstream.

It was possible for mac80211 to be coerced into an
unexpected flow causing sdata union to become
corrupted. Station pointer was put into
sdata->u.vlan.sta memory location while it was
really master AP's sdata->u.ap.next_beacon. This
led to station entry being later freed as
next_beacon before __sta_info_flush() in
ieee80211_stop_ap() and a subsequent invalid
pointer dereference crash.

The problem was that ieee80211_ptr->use_4addr
wasn't cleared on interface type changes.

This could be reproduced with the following steps:

 # host A and host B have just booted; no
 # wpa_s/hostapd running; all vifs are down
 host A> iw wlan0 set type station
 host A> iw wlan0 set 4addr on
 host A> printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' > /tmp/hconf
 host A> hostapd -B /tmp/conf
 host B> iw wlan0 set 4addr on
 host B> ifconfig wlan0 up
 host B> iw wlan0 connect -w hostAssid
 host A> pkill hostapd
 # host A crashed:

 [  127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8
 [  127.929014] IP: [] __sta_info_flush+0xac/0x158
 ...
 [  127.934578]  [] ieee80211_stop_ap+0x139/0x26c
 [  127.934578]  [] ? dump_trace+0x279/0x28a
 [  127.934578]  [] __cfg80211_stop_ap+0x84/0x191
 [  127.934578]  [] cfg80211_stop_ap+0x3f/0x58
 [  127.934578]  [] nl80211_stop_ap+0x1b/0x1d
 [  127.934578]  [] genl_family_rcv_msg+0x259/0x2b5

Note: This isn't a revert of f8cdddb8d61d
("cfg80211: check iface combinations only when
iface is running") as far as functionality is
considered because b6a550156bc ("cfg80211/mac80211:
move more combination checks to mac80211") moved
the logic somewhere else already.

Fixes: f8cdddb8d61d ("cfg80211: check iface combinations only when iface is running")
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: wext: clear sinfo struct before calling driver

2015-06-09T20:54:58+00:00

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

Cc: stable@vger.kernel.org
Reported-by: Gerrit Renker 
Reported-by: Alexander Kaltsas 
Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

cfg80211: don't allow disabling WEXT if it's required

2015-04-08T07:19:29+00:00

The change to only export WEXT symbols when required could break
the build if CONFIG_CFG80211_WEXT was explicitly disabled while
a driver like orinoco selected it.

Fix this by hiding the symbol when it's required so it can't be
disabled in that case.

Fixes: 2afe38d15cee ("cfg80211-wext: export symbols only when needed")
Reported-by: Randy Dunlap 
Reported-by: Jim Davis 
Signed-off-by: Johannes Berg

cfg80211: send extended capabilities IE in connect

2015-04-07T11:56:45+00:00

If the connect request from userspace didn't include an extended
capabilities IE, create one using the driver capabilities. This
fixes VHT associations, since those need to set the operating mode
notification capability.

Reviewed-by: Gregory Greenman 
Signed-off-by: Johannes Berg

cfg80211: move IE split utilities here from mac80211

2015-04-07T11:56:41+00:00

As the next patch will require the IE splitting utility functions
in cfg80211, move them there from mac80211.

Signed-off-by: Johannes Berg

cfg80211: Stop calling crda if it is not responsive

2015-04-01T09:22:38+00:00

Patch eeca9fce1d71a4955855ceb0c3b13c1eb9db27c1 (cfg80211: Schedule
timeout for all CRDA call) introduced a regression, where in case
that crda is not installed (or not configured properly etc.), the
regulatory core will needlessly continue to call it, polluting the
log with the following log:

"cfg80211: Calling CRDA to update world regulatory domain"

Fix this by limiting the number of continuous CRDA request failures.

Signed-off-by: Ilan Peer 
Signed-off-by: Johannes Berg