1. 11 3月, 2020 2 次提交
  2. 24 2月, 2020 1 次提交
  3. 21 2月, 2020 1 次提交
  4. 14 2月, 2020 1 次提交
  5. 15 1月, 2020 2 次提交
  6. 13 12月, 2019 1 次提交
  7. 08 11月, 2019 1 次提交
  8. 30 10月, 2019 1 次提交
  9. 11 10月, 2019 1 次提交
  10. 08 10月, 2019 1 次提交
  11. 01 10月, 2019 3 次提交
    • M
      nl80211: fix null pointer dereference · b501426c
      Miaoqing Pan 提交于
      If the interface is not in MESH mode, the command 'iw wlanx mpath del'
      will cause kernel panic.
      
      The root cause is null pointer access in mpp_flush_by_proxy(), as the
      pointer 'sdata->u.mesh.mpp_paths' is NULL for non MESH interface.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000068
      [...]
      PC is at _raw_spin_lock_bh+0x20/0x5c
      LR is at mesh_path_del+0x1c/0x17c [mac80211]
      [...]
      Process iw (pid: 4537, stack limit = 0xd83e0238)
      [...]
      [<c021211c>] (_raw_spin_lock_bh) from [<bf8c7648>] (mesh_path_del+0x1c/0x17c [mac80211])
      [<bf8c7648>] (mesh_path_del [mac80211]) from [<bf6cdb7c>] (extack_doit+0x20/0x68 [compat])
      [<bf6cdb7c>] (extack_doit [compat]) from [<c05c309c>] (genl_rcv_msg+0x274/0x30c)
      [<c05c309c>] (genl_rcv_msg) from [<c05c25d8>] (netlink_rcv_skb+0x58/0xac)
      [<c05c25d8>] (netlink_rcv_skb) from [<c05c2e14>] (genl_rcv+0x20/0x34)
      [<c05c2e14>] (genl_rcv) from [<c05c1f90>] (netlink_unicast+0x11c/0x204)
      [<c05c1f90>] (netlink_unicast) from [<c05c2420>] (netlink_sendmsg+0x30c/0x370)
      [<c05c2420>] (netlink_sendmsg) from [<c05886d0>] (sock_sendmsg+0x70/0x84)
      [<c05886d0>] (sock_sendmsg) from [<c0589f4c>] (___sys_sendmsg.part.3+0x188/0x228)
      [<c0589f4c>] (___sys_sendmsg.part.3) from [<c058add4>] (__sys_sendmsg+0x4c/0x70)
      [<c058add4>] (__sys_sendmsg) from [<c0208c80>] (ret_fast_syscall+0x0/0x44)
      Code: e2822c02 e2822001 e5832004 f590f000 (e1902f9f)
      ---[ end trace bbd717600f8f884d ]---
      Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
      Link: https://lore.kernel.org/r/1569485810-761-1-git-send-email-miaoqing@codeaurora.org
      [trim useless data from commit message]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b501426c
    • J
      cfg80211: initialize on-stack chandefs · f43e5210
      Johannes Berg 提交于
      In a few places we don't properly initialize on-stack chandefs,
      resulting in EDMG data to be non-zero, which broke things.
      
      Additionally, in a few places we rely on the driver to init the
      data completely, but perhaps we shouldn't as non-EDMG drivers
      may not initialize the EDMG data, also initialize it there.
      
      Cc: stable@vger.kernel.org
      Fixes: 2a38075c ("nl80211: Add support for EDMG channels")
      Reported-by: NDmitry Osipenko <digetx@gmail.com>
      Tested-by: NDmitry Osipenko <digetx@gmail.com>
      Link: https://lore.kernel.org/r/1569239475-I2dcce394ecf873376c386a78f31c2ec8b538fa25@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      f43e5210
    • J
      nl80211: validate beacon head · f88eb7c0
      Johannes Berg 提交于
      We currently don't validate the beacon head, i.e. the header,
      fixed part and elements that are to go in front of the TIM
      element. This means that the variable elements there can be
      malformed, e.g. have a length exceeding the buffer size, but
      most downstream code from this assumes that this has already
      been checked.
      
      Add the necessary checks to the netlink policy.
      
      Cc: stable@vger.kernel.org
      Fixes: ed1b6cc7 ("cfg80211/nl80211: add beacon settings")
      Link: https://lore.kernel.org/r/1569009255-I7ac7fbe9436e9d8733439eab8acbbd35e55c74ef@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      f88eb7c0
  12. 11 9月, 2019 2 次提交
  13. 30 8月, 2019 1 次提交
  14. 23 8月, 2019 1 次提交
  15. 21 8月, 2019 3 次提交
  16. 31 7月, 2019 3 次提交
  17. 29 7月, 2019 2 次提交
  18. 26 7月, 2019 2 次提交
  19. 14 6月, 2019 6 次提交
  20. 29 5月, 2019 1 次提交
  21. 28 5月, 2019 2 次提交
  22. 24 5月, 2019 1 次提交
    • M
      {nl,mac}80211: allow 4addr AP operation on crypto controlled devices · 33d915d9
      Manikanta Pubbisetty 提交于
      As per the current design, in the case of sw crypto controlled devices,
      it is the device which advertises the support for AP/VLAN iftype based
      on it's ability to tranmsit packets encrypted in software
      (In VLAN functionality, group traffic generated for a specific
      VLAN group is always encrypted in software). Commit db3bdcb9
      ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      has introduced this change.
      
      Since 4addr AP operation also uses AP/VLAN iftype, this conditional
      way of advertising AP/VLAN support has broken 4addr AP mode operation on
      crypto controlled devices which do not support VLAN functionality.
      
      In the case of ath10k driver, not all firmwares have support for VLAN
      functionality but all can support 4addr AP operation. Because AP/VLAN
      support is not advertised for these devices, 4addr AP operations are
      also blocked.
      
      Fix this by allowing 4addr operation on devices which do not support
      AP/VLAN iftype but can support 4addr AP operation (decision is based on
      the wiphy flag WIPHY_FLAG_4ADDR_AP).
      
      Cc: stable@vger.kernel.org
      Fixes: db3bdcb9 ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      33d915d9
  23. 21 5月, 2019 1 次提交