1. 08 10月, 2020 2 次提交
  2. 28 9月, 2020 1 次提交
  3. 18 9月, 2020 3 次提交
  4. 27 8月, 2020 1 次提交
  5. 31 7月, 2020 6 次提交
  6. 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
  7. 31 5月, 2020 2 次提交
  8. 27 5月, 2020 1 次提交
  9. 29 4月, 2020 1 次提交
  10. 24 4月, 2020 4 次提交
  11. 20 3月, 2020 2 次提交
  12. 24 2月, 2020 2 次提交
  13. 07 2月, 2020 2 次提交
  14. 15 1月, 2020 2 次提交
  15. 08 11月, 2019 1 次提交
  16. 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
  17. 21 8月, 2019 1 次提交
  18. 31 7月, 2019 2 次提交
  19. 21 7月, 2019 1 次提交
  20. 20 6月, 2019 1 次提交
  21. 14 6月, 2019 2 次提交
  22. 05 6月, 2019 1 次提交