1. 08 4月, 2021 1 次提交
    • S
      mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN · dd0b4553
      Seevalamuthu Mariappan 提交于
      In some race conditions, with more clients and traffic configuration,
      below crash is seen when making the interface down. sta->fast_rx wasn't
      cleared when STA gets removed from 4-addr AP_VLAN interface. The crash is
      due to try accessing 4-addr AP_VLAN interface's net_device (fast_rx->dev)
      which has been deleted already.
      
      Resolve this by clearing sta->fast_rx pointer when STA removes
      from a 4-addr VLAN.
      
      [  239.449529] Unable to handle kernel NULL pointer dereference at virtual address 00000004
      [  239.449531] pgd = 80204000
      ...
      [  239.481496] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.60 #227
      [  239.481591] Hardware name: Generic DT based system
      [  239.487665] task: be05b700 ti: be08e000 task.ti: be08e000
      [  239.492360] PC is at get_rps_cpu+0x2d4/0x31c
      [  239.497823] LR is at 0xbe08fc54
      ...
      [  239.778574] [<80739740>] (get_rps_cpu) from [<8073cb10>] (netif_receive_skb_internal+0x8c/0xac)
      [  239.786722] [<8073cb10>] (netif_receive_skb_internal) from [<8073d578>] (napi_gro_receive+0x48/0xc4)
      [  239.795267] [<8073d578>] (napi_gro_receive) from [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames+0xbcc/0x12d4 [mac80211])
      [  239.804776] [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames [mac80211]) from [<c7b84d4c>] (ieee80211_rx_napi+0x7b8/0x8c8 [mac8
                  0211])
      [  239.815857] [<c7b84d4c>] (ieee80211_rx_napi [mac80211]) from [<c7f63d7c>] (ath11k_dp_process_rx+0x7bc/0x8c8 [ath11k])
      [  239.827757] [<c7f63d7c>] (ath11k_dp_process_rx [ath11k]) from [<c7f5b6c4>] (ath11k_dp_service_srng+0x2c0/0x2e0 [ath11k])
      [  239.838484] [<c7f5b6c4>] (ath11k_dp_service_srng [ath11k]) from [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll+0x20/0x84 [ath11k_ahb]
                  )
      [  239.849419] [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll [ath11k_ahb]) from [<8073ce1c>] (net_rx_action+0xe0/0x28c)
      [  239.860945] [<8073ce1c>] (net_rx_action) from [<80324868>] (__do_softirq+0xe4/0x228)
      [  239.871269] [<80324868>] (__do_softirq) from [<80324c48>] (irq_exit+0x98/0x108)
      [  239.879080] [<80324c48>] (irq_exit) from [<8035c59c>] (__handle_domain_irq+0x90/0xb4)
      [  239.886114] [<8035c59c>] (__handle_domain_irq) from [<8030137c>] (gic_handle_irq+0x50/0x94)
      [  239.894100] [<8030137c>] (gic_handle_irq) from [<803024c0>] (__irq_svc+0x40/0x74)
      Signed-off-by: NSeevalamuthu Mariappan <seevalam@codeaurora.org>
      Link: https://lore.kernel.org/r/1616163532-3881-1-git-send-email-seevalam@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      dd0b4553
  2. 17 3月, 2021 1 次提交
  3. 11 12月, 2020 5 次提交
  4. 11 11月, 2020 1 次提交
  5. 08 10月, 2020 2 次提交
  6. 28 9月, 2020 1 次提交
  7. 18 9月, 2020 3 次提交
  8. 27 8月, 2020 1 次提交
  9. 31 7月, 2020 6 次提交
  10. 30 7月, 2020 1 次提交
    • R
      mac80211: mesh: Free ie data when leaving mesh · 6a01afcf
      Remi Pommarel 提交于
      At ieee80211_join_mesh() some ie data could have been allocated (see
      copy_mesh_setup()) and need to be cleaned up when leaving the mesh.
      
      This fixes the following kmemleak report:
      
      unreferenced object 0xffff0000116bc600 (size 128):
        comm "wpa_supplicant", pid 608, jiffies 4294898983 (age 293.484s)
        hex dump (first 32 bytes):
          30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00  0...............
          00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00  .........e@.....
        backtrace:
          [<00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
          [<00000000a349dbe1>] kmemdup+0x28/0x50
          [<0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
          [<00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
          [<0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
          [<0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
          [<00000000b1bd936d>] genl_rcv_msg+0x78/0x108
          [<0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
          [<0000000011af8ec9>] genl_rcv+0x34/0x48
          [<0000000069e41f53>] netlink_unicast+0x268/0x2e8
          [<00000000a7517316>] netlink_sendmsg+0x320/0x4c0
          [<0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
          [<00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
          [<0000000037340728>] __sys_sendmsg+0xa4/0xf8
          [<000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
          [<000000001c1e5647>] el0_svc_handler+0xd0/0x1a0
      
      Fixes: c80d545d (mac80211: Let userspace enable and configure vendor specific path selection.)
      Signed-off-by: NRemi Pommarel <repk@triplefau.lt>
      Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.ltSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      6a01afcf
  11. 31 5月, 2020 2 次提交
  12. 27 5月, 2020 1 次提交
  13. 29 4月, 2020 1 次提交
  14. 24 4月, 2020 4 次提交
  15. 20 3月, 2020 2 次提交
  16. 24 2月, 2020 2 次提交
  17. 07 2月, 2020 2 次提交
  18. 15 1月, 2020 2 次提交
  19. 08 11月, 2019 1 次提交
  20. 11 9月, 2019 1 次提交
    • J
      mac80211: Do not send Layer 2 Update frame before authorization · 3e493173
      Jouni Malinen 提交于
      The Layer 2 Update frame is used to update bridges when a station roams
      to another AP even if that STA does not transmit any frames after the
      reassociation. This behavior was described in IEEE Std 802.11F-2003 as
      something that would happen based on MLME-ASSOCIATE.indication, i.e.,
      before completing 4-way handshake. However, this IEEE trial-use
      recommended practice document was published before RSN (IEEE Std
      802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
      IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
      maintained amd should not be used anymore.
      
      Sending out the Layer 2 Update frame immediately after association is
      fine for open networks (and also when using SAE, FT protocol, or FILS
      authentication when the station is actually authenticated by the time
      association completes). However, it is not appropriate for cases where
      RSN is used with PSK or EAP authentication since the station is actually
      fully authenticated only once the 4-way handshake completes after
      authentication and attackers might be able to use the unauthenticated
      triggering of Layer 2 Update frame transmission to disrupt bridge
      behavior.
      
      Fix this by postponing transmission of the Layer 2 Update frame from
      station entry addition to the point when the station entry is marked
      authorized. Similarly, send out the VLAN binding update only if the STA
      entry has already been authorized.
      Signed-off-by: NJouni Malinen <jouni@codeaurora.org>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e493173