<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/mac80211, branch v3.14.78</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mac80211: fix purging multicast PS buffer queue</title>
<updated>2016-09-07T06:30:00+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2016-08-02T09:13:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=950af829a5fc32c34ae71e2e83f19d4dd58709b8'/>
<id>950af829a5fc32c34ae71e2e83f19d4dd58709b8</id>
<content type='text'>
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 &lt;nbd@nbd.name&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;nbd@nbd.name&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: mesh: flush mesh paths unconditionally</title>
<updated>2016-07-27T16:55:48+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2016-05-15T17:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eaf685aeb0e7d3a9aee0625e3a36685e7467b3b4'/>
<id>eaf685aeb0e7d3a9aee0625e3a36685e7467b3b4</id>
<content type='text'>
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
     -&gt; cleanup_single_sta
       -&gt; mesh_sta_cleanup
         -&gt; mesh_plink_deactivate
           -&gt; 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()
                                [...] -&gt; mesh_path_flush_by_nexthop()
  sta = rcu_dereference(
    mpath-&gt;next_hop)
                                kfree(sta)
  access sta &lt;-- 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: [&lt;f929245d&gt;] 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:[&lt;f929245d&gt;] 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]  [&lt;f9291d80&gt;] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
[  348.530014]  [&lt;f9291dc1&gt;] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
[  348.530014]  [&lt;f9277f6f&gt;] ieee80211_xmit+0x92/0xc1 [mac80211]
[  348.530014]  [&lt;f9278dd1&gt;] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
[  348.530014]  [&lt;c04df012&gt;] ? sch_direct_xmit+0xd7/0x1b3
[  348.530014]  [&lt;c022a8c6&gt;] ? __local_bh_enable_ip+0x5d/0x7b
[  348.530014]  [&lt;f956870c&gt;] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
[  348.530014]  [&lt;f957e036&gt;] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
[  348.530014]  [&lt;c04c6f45&gt;] ? netif_skb_features+0x14d/0x30a
[  348.530014]  [&lt;f9278e10&gt;] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f91bfc7a&gt;] batadv_send_skb_packet+0xd6/0xec [batman_adv]
[  348.530014]  [&lt;f91bfdc4&gt;] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
[  348.530014]  [&lt;f91b5938&gt;] batadv_dat_send_data+0x27e/0x310 [batman_adv]
[  348.530014]  [&lt;f91c30b5&gt;] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
[  348.530014]  [&lt;f91b63f3&gt;] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
[  348.530014]  [&lt;f91c0cd9&gt;] batadv_interface_tx+0x206/0x385 [batman_adv]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;f80cbd2a&gt;] ? igb_xmit_frame+0x57/0x72 [igb]
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f843a326&gt;] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
[  348.530014]  [&lt;f843a35f&gt;] br_forward_finish+0x29/0x74 [bridge]
[  348.530014]  [&lt;f843a23b&gt;] ? deliver_clone+0x3b/0x3b [bridge]
[  348.530014]  [&lt;f843a714&gt;] __br_forward+0x89/0xe7 [bridge]
[  348.530014]  [&lt;f843a336&gt;] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
[  348.530014]  [&lt;f843a234&gt;] deliver_clone+0x34/0x3b [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843a66d&gt;] br_flood+0x77/0x95 [bridge]
[  348.530014]  [&lt;f843a809&gt;] br_flood_forward+0x13/0x1a [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843b877&gt;] br_handle_frame_finish+0x392/0x3db [bridge]
[  348.530014]  [&lt;c04e9b2b&gt;] ? nf_iterate+0x2b/0x6b
[  348.530014]  [&lt;f843baa6&gt;] br_handle_frame+0x1e6/0x240 [bridge]
[  348.530014]  [&lt;f843b4e5&gt;] ? br_handle_local_finish+0x6a/0x6a [bridge]
[  348.530014]  [&lt;c04c4ba0&gt;] __netif_receive_skb_core+0x43a/0x66b
[  348.530014]  [&lt;f843b8c0&gt;] ? br_handle_frame_finish+0x3db/0x3db [bridge]
[  348.530014]  [&lt;c023cea4&gt;] ? resched_curr+0x19/0x37
[  348.530014]  [&lt;c0240707&gt;] ? check_preempt_wakeup+0xbf/0xfe
[  348.530014]  [&lt;c0255dec&gt;] ? ktime_get_with_offset+0x5c/0xfc
[  348.530014]  [&lt;c04c4fc1&gt;] __netif_receive_skb+0x47/0x55
[  348.530014]  [&lt;c04c57ba&gt;] netif_receive_skb_internal+0x40/0x5a
[  348.530014]  [&lt;c04c61ef&gt;] napi_gro_receive+0x3a/0x94
[  348.530014]  [&lt;f80ce8d5&gt;] igb_poll+0x6fd/0x9ad [igb]
[  348.530014]  [&lt;c0242bd8&gt;] ? swake_up_locked+0x14/0x26
[  348.530014]  [&lt;c04c5d29&gt;] net_rx_action+0xde/0x250
[  348.530014]  [&lt;c022a743&gt;] __do_softirq+0x8a/0x163
[  348.530014]  [&lt;c022a6b9&gt;] ? __hrtimer_tasklet_trampoline+0x19/0x19
[  348.530014]  [&lt;c021100f&gt;] do_softirq_own_stack+0x26/0x2c
[  348.530014]  &lt;IRQ&gt;
[  348.530014]  [&lt;c022a957&gt;] irq_exit+0x31/0x6f
[  348.530014]  [&lt;c0210eb2&gt;] do_IRQ+0x8d/0xa0
[  348.530014]  [&lt;c058152c&gt;] 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: [&lt;f929245d&gt;] 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 &lt;fred.veldini@gmail.com&gt;
Tested-by: Fred Veldini &lt;fred.veldini@gmail.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
     -&gt; cleanup_single_sta
       -&gt; mesh_sta_cleanup
         -&gt; mesh_plink_deactivate
           -&gt; 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()
                                [...] -&gt; mesh_path_flush_by_nexthop()
  sta = rcu_dereference(
    mpath-&gt;next_hop)
                                kfree(sta)
  access sta &lt;-- 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: [&lt;f929245d&gt;] 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:[&lt;f929245d&gt;] 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]  [&lt;f9291d80&gt;] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
[  348.530014]  [&lt;f9291dc1&gt;] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
[  348.530014]  [&lt;f9277f6f&gt;] ieee80211_xmit+0x92/0xc1 [mac80211]
[  348.530014]  [&lt;f9278dd1&gt;] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
[  348.530014]  [&lt;c04df012&gt;] ? sch_direct_xmit+0xd7/0x1b3
[  348.530014]  [&lt;c022a8c6&gt;] ? __local_bh_enable_ip+0x5d/0x7b
[  348.530014]  [&lt;f956870c&gt;] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
[  348.530014]  [&lt;f957e036&gt;] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
[  348.530014]  [&lt;c04c6f45&gt;] ? netif_skb_features+0x14d/0x30a
[  348.530014]  [&lt;f9278e10&gt;] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f91bfc7a&gt;] batadv_send_skb_packet+0xd6/0xec [batman_adv]
[  348.530014]  [&lt;f91bfdc4&gt;] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
[  348.530014]  [&lt;f91b5938&gt;] batadv_dat_send_data+0x27e/0x310 [batman_adv]
[  348.530014]  [&lt;f91c30b5&gt;] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
[  348.530014]  [&lt;f91b63f3&gt;] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
[  348.530014]  [&lt;f91c0cd9&gt;] batadv_interface_tx+0x206/0x385 [batman_adv]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;f80cbd2a&gt;] ? igb_xmit_frame+0x57/0x72 [igb]
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f843a326&gt;] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
[  348.530014]  [&lt;f843a35f&gt;] br_forward_finish+0x29/0x74 [bridge]
[  348.530014]  [&lt;f843a23b&gt;] ? deliver_clone+0x3b/0x3b [bridge]
[  348.530014]  [&lt;f843a714&gt;] __br_forward+0x89/0xe7 [bridge]
[  348.530014]  [&lt;f843a336&gt;] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
[  348.530014]  [&lt;f843a234&gt;] deliver_clone+0x34/0x3b [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843a66d&gt;] br_flood+0x77/0x95 [bridge]
[  348.530014]  [&lt;f843a809&gt;] br_flood_forward+0x13/0x1a [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843b877&gt;] br_handle_frame_finish+0x392/0x3db [bridge]
[  348.530014]  [&lt;c04e9b2b&gt;] ? nf_iterate+0x2b/0x6b
[  348.530014]  [&lt;f843baa6&gt;] br_handle_frame+0x1e6/0x240 [bridge]
[  348.530014]  [&lt;f843b4e5&gt;] ? br_handle_local_finish+0x6a/0x6a [bridge]
[  348.530014]  [&lt;c04c4ba0&gt;] __netif_receive_skb_core+0x43a/0x66b
[  348.530014]  [&lt;f843b8c0&gt;] ? br_handle_frame_finish+0x3db/0x3db [bridge]
[  348.530014]  [&lt;c023cea4&gt;] ? resched_curr+0x19/0x37
[  348.530014]  [&lt;c0240707&gt;] ? check_preempt_wakeup+0xbf/0xfe
[  348.530014]  [&lt;c0255dec&gt;] ? ktime_get_with_offset+0x5c/0xfc
[  348.530014]  [&lt;c04c4fc1&gt;] __netif_receive_skb+0x47/0x55
[  348.530014]  [&lt;c04c57ba&gt;] netif_receive_skb_internal+0x40/0x5a
[  348.530014]  [&lt;c04c61ef&gt;] napi_gro_receive+0x3a/0x94
[  348.530014]  [&lt;f80ce8d5&gt;] igb_poll+0x6fd/0x9ad [igb]
[  348.530014]  [&lt;c0242bd8&gt;] ? swake_up_locked+0x14/0x26
[  348.530014]  [&lt;c04c5d29&gt;] net_rx_action+0xde/0x250
[  348.530014]  [&lt;c022a743&gt;] __do_softirq+0x8a/0x163
[  348.530014]  [&lt;c022a6b9&gt;] ? __hrtimer_tasklet_trampoline+0x19/0x19
[  348.530014]  [&lt;c021100f&gt;] do_softirq_own_stack+0x26/0x2c
[  348.530014]  &lt;IRQ&gt;
[  348.530014]  [&lt;c022a957&gt;] irq_exit+0x31/0x6f
[  348.530014]  [&lt;c0210eb2&gt;] do_IRQ+0x8d/0xa0
[  348.530014]  [&lt;c058152c&gt;] 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: [&lt;f929245d&gt;] 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 &lt;fred.veldini@gmail.com&gt;
Tested-by: Fred Veldini &lt;fred.veldini@gmail.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix unnecessary frame drops in mesh fwding</title>
<updated>2016-04-20T06:40:44+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2016-01-25T13:43:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8c755b42de3b709056b210e9e2ccde0676c713d0'/>
<id>8c755b42de3b709056b210e9e2ccde0676c713d0</id>
<content type='text'>
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 &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: minstrel_ht: set default tx aggregation timeout to 0</title>
<updated>2016-03-16T15:42:20+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2016-02-18T18:49:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c0026457e7b3eb75a8952cda06065ec0aca9bde'/>
<id>2c0026457e7b3eb75a8952cda06065ec0aca9bde</id>
<content type='text'>
commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 upstream.

The value 5000 was put here with the addition of the timeout field to
ieee80211_start_tx_ba_session. It was originally added in mac80211 to
save resources for drivers like iwlwifi, which only supports a limited
number of concurrent aggregation sessions.

Since iwlwifi does not use minstrel_ht and other drivers don't need
this, 0 is a better default - especially since there have been
recent reports of aggregation setup related issues reproduced with
ath9k. This should improve stability without causing any adverse
effects.

Acked-by: Avery Pennarun &lt;apenwarr@gmail.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 upstream.

The value 5000 was put here with the addition of the timeout field to
ieee80211_start_tx_ba_session. It was originally added in mac80211 to
save resources for drivers like iwlwifi, which only supports a limited
number of concurrent aggregation sessions.

Since iwlwifi does not use minstrel_ht and other drivers don't need
this, 0 is a better default - especially since there have been
recent reports of aggregation setup related issues reproduced with
ath9k. This should improve stability without causing any adverse
effects.

Acked-by: Avery Pennarun &lt;apenwarr@gmail.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix use of uninitialised values in RX aggregation</title>
<updated>2016-03-16T15:42:20+00:00</updated>
<author>
<name>Chris Bainbridge</name>
<email>chris.bainbridge@gmail.com</email>
</author>
<published>2016-01-27T15:46:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=46d3dcc28f3f0c2f4bb612f1d59f50f529f7875c'/>
<id>46d3dcc28f3f0c2f4bb612f1d59f50f529f7875c</id>
<content type='text'>
commit f39ea2690bd61efec97622c48323f40ed6e16317 upstream.

Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
initialize the "removed" field (all others are initialized
manually). That fixes:

UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
load of value 2 is not a valid value for type '_Bool'
CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
Workqueue: phy0 rt2x00usb_work_rxdone
 0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
 ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
 ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
Call Trace:
 [&lt;ffffffff8181d866&gt;] dump_stack+0x45/0x5f
 [&lt;ffffffff8188422d&gt;] ubsan_epilogue+0xd/0x40
 [&lt;ffffffff81884747&gt;] __ubsan_handle_load_invalid_value+0x67/0x70
 [&lt;ffffffff82227b4d&gt;] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
 [&lt;ffffffff8222ca14&gt;] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
 [&lt;ffffffff8222db03&gt;] __ieee80211_rx_handle_packet+0x1f3/0x750
 [&lt;ffffffff8222e4a7&gt;] ieee80211_rx_napi+0x447/0x990

While at it, convert to use sizeof(*tid_agg_rx) instead.

Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
[reword commit message, use sizeof(*tid_agg_rx)]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f39ea2690bd61efec97622c48323f40ed6e16317 upstream.

Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
initialize the "removed" field (all others are initialized
manually). That fixes:

UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
load of value 2 is not a valid value for type '_Bool'
CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
Workqueue: phy0 rt2x00usb_work_rxdone
 0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
 ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
 ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
Call Trace:
 [&lt;ffffffff8181d866&gt;] dump_stack+0x45/0x5f
 [&lt;ffffffff8188422d&gt;] ubsan_epilogue+0xd/0x40
 [&lt;ffffffff81884747&gt;] __ubsan_handle_load_invalid_value+0x67/0x70
 [&lt;ffffffff82227b4d&gt;] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
 [&lt;ffffffff8222ca14&gt;] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
 [&lt;ffffffff8222db03&gt;] __ieee80211_rx_handle_packet+0x1f3/0x750
 [&lt;ffffffff8222e4a7&gt;] ieee80211_rx_napi+0x447/0x990

While at it, convert to use sizeof(*tid_agg_rx) instead.

Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
[reword commit message, use sizeof(*tid_agg_rx)]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: mesh: fix call_rcu() usage</title>
<updated>2016-03-03T23:06:49+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-11-17T13:25:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e65a06366da51b0b5c5b2c77804be1529406842'/>
<id>1e65a06366da51b0b5c5b2c77804be1529406842</id>
<content type='text'>
commit c2e703a55245bfff3db53b1f7cbe59f1ee8a4339 upstream.

When using call_rcu(), the called function may be delayed quite
significantly, and without a matching rcu_barrier() there's no
way to be sure it has finished.
Therefore, global state that could be gone/freed/reused should
never be touched in the callback.

Fix this in mesh by moving the atomic_dec() into the caller;
that's not really a problem since we already unlinked the path
and it will be destroyed anyway.

This fixes a crash Jouni observed when running certain tests in
a certain order, in which the mesh interface was torn down, the
memory reused for a function pointer (work struct) and running
that then crashed since the pointer had been decremented by 1,
resulting in an invalid instruction byte stream.

Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c2e703a55245bfff3db53b1f7cbe59f1ee8a4339 upstream.

When using call_rcu(), the called function may be delayed quite
significantly, and without a matching rcu_barrier() there's no
way to be sure it has finished.
Therefore, global state that could be gone/freed/reused should
never be touched in the callback.

Fix this in mesh by moving the atomic_dec() into the caller;
that's not really a problem since we already unlinked the path
and it will be destroyed anyway.

This fixes a crash Jouni observed when running certain tests in
a certain order, in which the mesh interface was torn down, the
memory reused for a function pointer (work struct) and running
that then crashed since the pointer had been decremented by 1,
resulting in an invalid instruction byte stream.

Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix driver RSSI event calculations</title>
<updated>2015-12-09T18:42:57+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-08-28T08:52:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=66f7cf4bcc98dc5f1cccd6e413bcc299a1392c51'/>
<id>66f7cf4bcc98dc5f1cccd6e413bcc299a1392c51</id>
<content type='text'>
commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.

The ifmgd-&gt;ave_beacon_signal value cannot be taken as is for
comparisons, it must be divided by since it's represented
like that for better accuracy of the EWMA calculations. This
would lead to invalid driver RSSI events. Fix the used value.

Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.

The ifmgd-&gt;ave_beacon_signal value cannot be taken as is for
comparisons, it must be divided by since it's represented
like that for better accuracy of the EWMA calculations. This
would lead to invalid driver RSSI events. Fix the used value.

Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: enable assoc check for mesh interfaces</title>
<updated>2015-10-01T09:36:09+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2015-06-13T14:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e0c3882922823cc90f5930c78c0fbcb217156b7'/>
<id>3e0c3882922823cc90f5930c78c0fbcb217156b7</id>
<content type='text'>
commit 3633ebebab2bbe88124388b7620442315c968e8f upstream.

We already set a station to be associated when peering completes, both
in user space and in the kernel.  Thus we should always have an
associated sta before sending data frames to that station.

Failure to check assoc state can cause crashes in the lower-level driver
due to transmitting unicast data frames before driver sta structures
(e.g. ampdu state in ath9k) are initialized.  This occurred when
forwarding in the presence of fixed mesh paths: frames were transmitted
to stations with whom we hadn't yet completed peering.

Reported-by: Alexis Green &lt;agreen@cococorp.com&gt;
Tested-by: Jesse Jones &lt;jjones@cococorp.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3633ebebab2bbe88124388b7620442315c968e8f upstream.

We already set a station to be associated when peering completes, both
in user space and in the kernel.  Thus we should always have an
associated sta before sending data frames to that station.

Failure to check assoc state can cause crashes in the lower-level driver
due to transmitting unicast data frames before driver sta structures
(e.g. ampdu state in ath9k) are initialized.  This occurred when
forwarding in the presence of fixed mesh paths: frames were transmitted
to stations with whom we hadn't yet completed peering.

Reported-by: Alexis Green &lt;agreen@cococorp.com&gt;
Tested-by: Jesse Jones &lt;jjones@cococorp.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: clear subdir_stations when removing debugfs</title>
<updated>2015-08-10T19:21:05+00:00</updated>
<author>
<name>Tom Hughes</name>
<email>tom@compton.nu</email>
</author>
<published>2015-06-29T18:41:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4cefd0dbbfae0ebb5563073681aaf77b2c43c9b8'/>
<id>4cefd0dbbfae0ebb5563073681aaf77b2c43c9b8</id>
<content type='text'>
commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream.

If we don't do this, and we then fail to recreate the debugfs
directory during a mode change, then we will fail later trying
to add stations to this now bogus directory:

BUG: unable to handle kernel NULL pointer dereference at 0000006c
IP: [&lt;c0a92202&gt;] mutex_lock+0x12/0x30
Call Trace:
[&lt;c0678ab4&gt;] start_creating+0x44/0xc0
[&lt;c0679203&gt;] debugfs_create_dir+0x13/0xf0
[&lt;f8a938ae&gt;] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]

Signed-off-by: Tom Hughes &lt;tom@compton.nu&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream.

If we don't do this, and we then fail to recreate the debugfs
directory during a mode change, then we will fail later trying
to add stations to this now bogus directory:

BUG: unable to handle kernel NULL pointer dereference at 0000006c
IP: [&lt;c0a92202&gt;] mutex_lock+0x12/0x30
Call Trace:
[&lt;c0678ab4&gt;] start_creating+0x44/0xc0
[&lt;c0679203&gt;] debugfs_create_dir+0x13/0xf0
[&lt;f8a938ae&gt;] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]

Signed-off-by: Tom Hughes &lt;tom@compton.nu&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: prevent possible crypto tx tailroom corruption</title>
<updated>2015-08-03T16:29:58+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2015-05-22T08:22:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5ea1b03950b3c587b837d20bd11715d1430c010b'/>
<id>5ea1b03950b3c587b837d20bd11715d1430c010b</id>
<content type='text'>
commit ab499db80fcf07c18e4053f91a619500f663e90e upstream.

There was a possible race between
ieee80211_reconfig() and
ieee80211_delayed_tailroom_dec(). This could
result in inability to transmit data if driver
crashed during roaming or rekeying and subsequent
skbs with insufficient tailroom appeared.

This race was probably never seen in the wild
because a device driver would have to crash AND
recover within 0.5s which is very unlikely.

I was able to prove this race exists after
changing the delay to 10s locally and crashing
ath10k via debugfs immediately after GTK
rekeying. In case of ath10k the counter went below
0. This was harmless but other drivers which
actually require tailroom (e.g. for WEP ICV or
MMIC) could end up with the counter at 0 instead
of &gt;0 and introduce insufficient skb tailroom
failures because mac80211 would not resize skbs
appropriately anymore.

Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming")
Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab499db80fcf07c18e4053f91a619500f663e90e upstream.

There was a possible race between
ieee80211_reconfig() and
ieee80211_delayed_tailroom_dec(). This could
result in inability to transmit data if driver
crashed during roaming or rekeying and subsequent
skbs with insufficient tailroom appeared.

This race was probably never seen in the wild
because a device driver would have to crash AND
recover within 0.5s which is very unlikely.

I was able to prove this race exists after
changing the delay to 10s locally and crashing
ath10k via debugfs immediately after GTK
rekeying. In case of ath10k the counter went below
0. This was harmless but other drivers which
actually require tailroom (e.g. for WEP ICV or
MMIC) could end up with the counter at 0 instead
of &gt;0 and introduce insufficient skb tailroom
failures because mac80211 would not resize skbs
appropriately anymore.

Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming")
Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
