1. 08 10月, 2019 1 次提交
  2. 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
  3. 11 9月, 2019 2 次提交
  4. 30 8月, 2019 1 次提交
  5. 23 8月, 2019 1 次提交
  6. 21 8月, 2019 3 次提交
  7. 31 7月, 2019 3 次提交
  8. 29 7月, 2019 2 次提交
  9. 26 7月, 2019 2 次提交
  10. 14 6月, 2019 6 次提交
  11. 29 5月, 2019 1 次提交
  12. 28 5月, 2019 2 次提交
  13. 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
  14. 21 5月, 2019 1 次提交
  15. 28 4月, 2019 3 次提交
    • J
      genetlink: optionally validate strictly/dumps · ef6243ac
      Johannes Berg 提交于
      Add options to strictly validate messages and dump messages,
      sometimes perhaps validating dump messages non-strictly may
      be required, so add an option for that as well.
      
      Since none of this can really be applied to existing commands,
      set the options everwhere using the following spatch:
      
          @@
          identifier ops;
          expression X;
          @@
          struct genl_ops ops[] = {
          ...,
           {
                  .cmd = X,
          +       .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
                  ...
           },
          ...
          };
      
      For new commands one should just not copy the .validate 'opt-out'
      flags and thus get strict validation.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef6243ac
    • J
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg 提交于
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb08174
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  16. 26 4月, 2019 6 次提交
  17. 08 4月, 2019 2 次提交
    • S
      cfg80211/nl80211: Offload OWE processing to user space in AP mode · cb74e977
      Sunil Dutt 提交于
      This interface allows the host driver to offload OWE processing
      to user space. This intends to support OWE (Opportunistic Wireless
      Encryption) AKM by the drivers that implement SME but rely on the
      user space for the cryptographic/OWE processing in AP mode. Such
      drivers are not capable of processing/deriving the DH IE.
      
      A new NL80211 command - NL80211_CMD_UPDATE_OWE_INFO is introduced
      to send the request/event between the host driver and user space.
      
      Driver shall provide the OWE info (MAC address and DH IE) of
      the peer to user space for cryptographic processing of the DH IE
      through the event. Accordingly, the user space shall update the
      OWE info/DH IE to the driver.
      
      Following is the sequence in AP mode for OWE authentication.
      
      Driver passes the OWE info obtained from the peer in the
      Association Request to the user space through the event
      cfg80211_update_owe_info_event. User space shall process the
      OWE info received and generate new OWE info. This OWE info is
      passed to the driver through NL80211_CMD_UPDATE_OWE_INFO
      request. Driver eventually uses this OWE info to send the
      Association Response to the peer.
      
      This OWE info in the command interface carries the IEs that include
      PMKID of the peer if the PMKSA is still valid or an updated DH IE
      for generating a new PMKSA with the peer.
      Signed-off-by: NLiangwei Dong <liangwei@codeaurora.org>
      Signed-off-by: NSunil Dutt <usdutt@codeaurora.org>
      Signed-off-by: NSrinivas Dasari <dasaris@codeaurora.org>
      [remove policy initialization - no longer exists]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cb74e977
    • N
      mac80211: Add support for NL80211_STA_INFO_AIRTIME_LINK_METRIC · ab60633c
      Narayanraddi Masti 提交于
      Add support for mesh airtime link metric attribute
      NL80211_STA_INFO_AIRTIME_LINK_METRIC.
      Signed-off-by: NNarayanraddi Masti <team.nmasti@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ab60633c