linux-toradex.git/net/mac80211, branch v4.4.36

mac80211: discard multicast and 4-addr A-MSDUs

2016-11-10T15:36:35+00:00

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.

In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
 * drop A-MSDUs with a multicast A1 (RA), as required by the
   spec in 9.11 (802.11-2012 version)
 * drop A-MSDUs with a 4-addr header, since the fourth address
   can't actually be useful for them; unless 4-address frame
   format is actually requested, even though the fourth address
   is still not useful in this case, but ignored

Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.

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

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