linux-stable.git/net/mac80211, branch v4.4.30

mac80211: fix purging multicast PS buffer queue

2016-09-07T06:32:41+00:00

commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 upstream.

The code currently assumes that buffered multicast PS frames don't have
a pending ACK frame for tx status reporting.
However, hostapd sends a broadcast deauth frame on teardown for which tx
status is requested. This can lead to the "Have pending ack frames"
warning on module reload.
Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: Fix mesh estab_plinks counting in STA removal case

2016-07-27T16:47:27+00:00

commit 126e7557328a1cd576be4fca95b133a2695283ff upstream.

If a user space program (e.g., wpa_supplicant) deletes a STA entry that
is currently in NL80211_PLINK_ESTAB state, the number of established
plinks counter was not decremented and this could result in rejecting
new plink establishment before really hitting the real maximum plink
limit. For !user_mpm case, this decrementation is handled by
mesh_plink_deactive().

Fix this by decrementing estab_plinks on STA deletion
(mesh_sta_cleanup() gets called from there) so that the counter has a
correct value and the Beacon frame advertisement in Mesh Configuration
element shows the proper value for capability to accept additional
peers.

Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: mesh: flush mesh paths unconditionally

2016-07-27T16:47:27+00:00

commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 upstream.

Currently, the mesh paths associated with a nexthop station are cleaned
up in the following code path:

    __sta_info_destroy_part1
    synchronize_net()
    __sta_info_destroy_part2
     -> cleanup_single_sta
       -> mesh_sta_cleanup
         -> mesh_plink_deactivate
           -> mesh_path_flush_by_nexthop

However, there are a couple of problems here:

1) the paths aren't flushed at all if the MPM is running in userspace
   (e.g. when using wpa_supplicant or authsae)

2) there is no synchronize_rcu between removing the path and readers
   accessing the nexthop, which means the following race is possible:

CPU0                            CPU1
~~~~                            ~~~~
                                sta_info_destroy_part1()
                                synchronize_net()
rcu_read_lock()
mesh_nexthop_resolve()
  mpath = mesh_path_lookup()
                                [...] -> mesh_path_flush_by_nexthop()
  sta = rcu_dereference(
    mpath->next_hop)
                                kfree(sta)
  access sta <-- CRASH

Fix both of these by unconditionally flushing paths before destroying
the sta, and by adding a synchronize_net() after path flush to ensure
no active readers can still dereference the sta.

Fixes this crash:

[  348.529295] BUG: unable to handle kernel paging request at 00020040
[  348.530014] IP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[  348.530014] *pde = 00000000
[  348.530014] Oops: 0000 [#1] PREEMPT
[  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
[  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
[  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
[  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
[  348.530014] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
[  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
[  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
[  348.530014] Stack:
[  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
[  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
[  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
[  348.530014] Call Trace:
[  348.530014]  [] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
[  348.530014]  [] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
[  348.530014]  [] ieee80211_xmit+0x92/0xc1 [mac80211]
[  348.530014]  [] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
[  348.530014]  [] ? sch_direct_xmit+0xd7/0x1b3
[  348.530014]  [] ? __local_bh_enable_ip+0x5d/0x7b
[  348.530014]  [] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
[  348.530014]  [] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
[  348.530014]  [] ? netif_skb_features+0x14d/0x30a
[  348.530014]  [] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
[  348.530014]  [] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [] dev_queue_xmit+0xa/0xc
[  348.530014]  [] batadv_send_skb_packet+0xd6/0xec [batman_adv]
[  348.530014]  [] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
[  348.530014]  [] batadv_dat_send_data+0x27e/0x310 [batman_adv]
[  348.530014]  [] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
[  348.530014]  [] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
[  348.530014]  [] batadv_interface_tx+0x206/0x385 [batman_adv]
[  348.530014]  [] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [] ? igb_xmit_frame+0x57/0x72 [igb]
[  348.530014]  [] dev_queue_xmit+0xa/0xc
[  348.530014]  [] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
[  348.530014]  [] br_forward_finish+0x29/0x74 [bridge]
[  348.530014]  [] ? deliver_clone+0x3b/0x3b [bridge]
[  348.530014]  [] __br_forward+0x89/0xe7 [bridge]
[  348.530014]  [] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
[  348.530014]  [] deliver_clone+0x34/0x3b [bridge]
[  348.530014]  [] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [] br_flood+0x77/0x95 [bridge]
[  348.530014]  [] br_flood_forward+0x13/0x1a [bridge]
[  348.530014]  [] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [] br_handle_frame_finish+0x392/0x3db [bridge]
[  348.530014]  [] ? nf_iterate+0x2b/0x6b
[  348.530014]  [] br_handle_frame+0x1e6/0x240 [bridge]
[  348.530014]  [] ? br_handle_local_finish+0x6a/0x6a [bridge]
[  348.530014]  [] __netif_receive_skb_core+0x43a/0x66b
[  348.530014]  [] ? br_handle_frame_finish+0x3db/0x3db [bridge]
[  348.530014]  [] ? resched_curr+0x19/0x37
[  348.530014]  [] ? check_preempt_wakeup+0xbf/0xfe
[  348.530014]  [] ? ktime_get_with_offset+0x5c/0xfc
[  348.530014]  [] __netif_receive_skb+0x47/0x55
[  348.530014]  [] netif_receive_skb_internal+0x40/0x5a
[  348.530014]  [] napi_gro_receive+0x3a/0x94
[  348.530014]  [] igb_poll+0x6fd/0x9ad [igb]
[  348.530014]  [] ? swake_up_locked+0x14/0x26
[  348.530014]  [] net_rx_action+0xde/0x250
[  348.530014]  [] __do_softirq+0x8a/0x163
[  348.530014]  [] ? __hrtimer_tasklet_trampoline+0x19/0x19
[  348.530014]  [] do_softirq_own_stack+0x26/0x2c
[  348.530014]  
[  348.530014]  [] irq_exit+0x31/0x6f
[  348.530014]  [] do_IRQ+0x8d/0xa0
[  348.530014]  [] common_interrupt+0x2c/0x40
[  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
[  348.530014] EIP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
[  348.530014] CR2: 0000000000020040
[  348.530014] ---[ end trace 48556ac26779732e ]---
[  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
[  348.530014] Kernel Offset: disabled

Reported-by: Fred Veldini 
Tested-by: Fred Veldini 
Signed-off-by: Bob Copeland 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix fast_tx header alignment

2016-07-27T16:47:27+00:00

commit 6fe04128f158c5ad27e7504bfdf1b12e63331bc9 upstream.

The header field is defined as u8[] but also accessed as struct
ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary
unaligned accesses, which can be very harmful for performance on many
platforms.

Fixes: e495c24731a2 ("mac80211: extend fast-xmit for more ciphers")
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix statistics leak if dev_alloc_name() fails

2016-05-11T09:21:13+00:00

commit e6436be21e77e3659b4ff7e357ab5a8342d132d2 upstream.

In the case that dev_alloc_name() fails, e.g. because the name was
given by the user and already exists, we need to clean up properly
and free the per-CPU statistics. Fix that.

Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics")
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix txq queue related crashes

2016-04-20T06:42:11+00:00

commit 2a58d42c1e018ad514d4e23fd33fb2ded95d3ee6 upstream.

The driver can access the queue simultanously
while mac80211 tears down the interface. Without
spinlock protection this could lead to corrupting
sk_buff_head and subsequently to an invalid
pointer dereference.

Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation")
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix unnecessary frame drops in mesh fwding

2016-04-20T06:42:10+00:00

commit cf44012810ccdd8fd947518e965cb04b7b8498be upstream.

The ieee80211_queue_stopped() expects hw queue
number but it was given raw WMM AC number instead.

This could cause frame drops and problems with
traffic in some cases - most notably if driver
doesn't map AC numbers to queue numbers 1:1 and
uses ieee80211_stop_queues() and
ieee80211_wake_queue() only without ever calling
ieee80211_wake_queues().

On ath10k it was possible to hit this problem in
the following case:

  1. wlan0 uses queue 0
     (ath10k maps queues per vif)
  2. offchannel uses queue 15
  3. queues 1-14 are unused
  4. ieee80211_stop_queues()
  5. ieee80211_wake_queue(q=0)
  6. ieee80211_wake_queue(q=15)
     (other queues are not woken up because both
      driver and mac80211 know other queues are
      unused)
  7. ieee80211_rx_h_mesh_fwding()
  8. ieee80211_select_queue_80211() returns 2
  9. ieee80211_queue_stopped(q=2) returns true
 10. frame is dropped (oops!)

Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping")
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix ibss scan parameters

2016-04-20T06:42:10+00:00

commit d321cd014e51baab475efbdec468255b9e0ec822 upstream.

When joining IBSS a full scan should be initiated in order to search
for existing cell, unless the fixed_channel parameter was set.
A default channel to create the IBSS on if no cell was found is
provided as well.
However - a scan is initiated only on the default channel provided
regardless of whether ifibss->fixed_channel is set or not, with the
obvious result of the cell not joining existing IBSS cell that is
on another channel.

Fixes: 76bed0f43b27 ("mac80211: IBSS fix scan request")
Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: avoid excessive stack usage in sta_info

2016-04-20T06:42:10+00:00

commit 0ef049dc1167fe834d0ad5d63f89eddc5c70f6e4 upstream.

When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
function consumes more stack than normally, exceeding the
1024 byte limit on ARM:

net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

It turns out that there are two functions that put a 'struct station_info'
on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
this structure alone requires up to 792 bytes.

Hoping that both are called rarely enough, this replaces the
on-stack structure with a dynamic allocation, which unfortunately
requires some suboptimal error handling for out-of-memory.

The __sta_info_destroy_part2 function is actually affected by the
stack usage twice because it calls cfg80211_del_sta_sinfo(), which
has another instance of struct station_info on its stack.

Signed-off-by: Arnd Bergmann 
Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events")
Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event")
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: properly deal with station hashtable insert errors

2016-04-20T06:42:10+00:00

commit 62b14b241ca6f790a17ccd9dd9f62ce1b006d406 upstream.

The original hand-implemented hash-table in mac80211 couldn't result
in insertion errors, and while converting to rhashtable I evidently
forgot to check the errors.

This surfaced now only because Ben is adding many identical keys and
that resulted in hidden insertion errors.

Fixes: 7bedd0cfad4e1 ("mac80211: use rhashtable for station table")
Reported-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman