1. 16 Sep, 2014 3 commits
  2. 15 Sep, 2014 3 commits
  3. 14 Sep, 2014 2 commits
  4. 12 Sep, 2014 1 commit
  5. 11 Sep, 2014 8 commits
  6. 09 Sep, 2014 6 commits
  7. 08 Sep, 2014 17 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix dereferencing conn variable before NULL check · c68b7f12
      Johan Hedberg authored
      This patch fixes the following type of static analyzer warning (and
      probably a real bug as well as the NULL check should be there for a
      reason):
      
      net/bluetooth/smp.c:1182 smp_conn_security() warn: variable dereferenced before check 'conn' (see line 1174)
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c68b7f12
    • Behan Webster's avatar
      Bluetooth: LLVMLinux: Remove VLAIS from bluetooth/amp.c · 9f06a8d6
      Behan Webster authored
      Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
      compliant equivalent. This patch allocates the appropriate amount of memory
      using an char array.
      
      The new code can be compiled with both gcc and clang.
      
      struct shash_desc contains a flexible array member member ctx declared with
      CRYPTO_MINALIGN_ATTR, so sizeof(struct shash_desc) aligns the beginning
      of the array declared after struct shash_desc with long long.
      
      No trailing padding is required because it is not a struct type that can
      be used in an array.
      
      The CRYPTO_MINALIGN_ATTR is required so that desc is aligned with long long
      as would be the case for a struct containing a member with
      CRYPTO_MINALIGN_ATTR.
      Signed-off-by: default avatarBehan Webster <behanw@converseincode.com>
      Signed-off-by: default avatarMark Charlebois <charlebm@gmail.com>
      Signed-off-by: default avatarJan-Simon Möller <dl9pf@gmx.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9f06a8d6
    • Johan Hedberg's avatar
      Bluetooth: Add strict checks for allowed SMP PDUs · b28b4943
      Johan Hedberg authored
      SMP defines quite clearly when certain PDUs are to be expected/allowed
      and when not, but doesn't have any explicit request/response definition.
      So far the code has relied on each PDU handler to behave correctly if
      receiving PDUs at an unexpected moment, however this requires many
      different checks and is prone to errors.
      
      This patch introduces a generic way to keep track of allowed PDUs and
      thereby reduces the responsibility & load on individual command
      handlers. The tracking is implemented using a simple bit-mask where each
      opcode maps to its own bit. If the bit is set the corresponding PDU is
      allow and if the bit is not set the PDU is not allowed.
      
      As a simple example, when we send the Pairing Request we'd set the bit
      for Pairing Response, and when we receive the Pairing Response we'd
      clear the bit for Pairing Response.
      
      Since the disallowed PDU rejection is now done in a single central place
      we need to be a bit careful of which action makes most sense to all
      cases. Previously some, such as Security Request, have been simply
      ignored whereas others have caused an explicit disconnect.
      
      The only PDU rejection action that keeps good interoperability and can
      be used for all the applicable use cases is to drop the data. This may
      raise some concerns of us now being more lenient for misbehaving (and
      potentially malicious) devices, but the policy of simply dropping data
      has been a successful one for many years e.g. in L2CAP (where this is
      the *only* policy for such cases - we never request disconnection in
      l2cap_core.c because of bad data). Furthermore, we cannot prevent
      connected devices from creating the SMP context (through a Security or
      Pairing Request), and once the context exists looking up the
      corresponding bit for the received opcode and deciding to reject it is
      essentially an equally lightweight operation as the kind of rejection
      that l2cap_core.c already successfully does.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b28b4943
    • Johan Hedberg's avatar
      Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys · c6e81e9a
      Johan Hedberg authored
      When we're in the process of receiving keys in phase 3 of SMP we keep
      track of which keys are still expected in the smp->remote_key_dist
      variable. If we still have some key bits set we need to continue waiting
      for more PDUs and not needlessly call smp_distribute_keys(). This patch
      fixes two such cases in the smp_cmd_master_ident() and
      smp_cmd_ident_addr_info() handler functions.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c6e81e9a
    • Johan Hedberg's avatar
      Bluetooth: Add define for key distribution mask · 88d3a8ac
      Johan Hedberg authored
      This patch adds a define for the allowed bits of the key distribution
      mask so we don't have to have magic 0x07 constants throughout the code.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      88d3a8ac
    • Johan Hedberg's avatar
      Bluetooth: Fix locking of the SMP context · fc75cc86
      Johan Hedberg authored
      Before the move the l2cap_chan the SMP context (smp_chan) didn't have
      any kind of proper locking. The best there existed was the
      HCI_CONN_LE_SMP_PEND flag which was used to enable mutual exclusion for
      potential multiple creators of the SMP context.
      
      Now that SMP has been converted to use the l2cap_chan infrastructure and
      since the SMP context is directly mapped to a corresponding l2cap_chan
      we get the SMP context locking essentially for free through the
      l2cap_chan lock. For all callbacks that l2cap_core.c makes for each
      channel implementation (smp.c in the case of SMP) the l2cap_chan lock is
      held through l2cap_chan_lock(chan).
      
      Since the calls from l2cap_core.c to smp.c are covered the only missing
      piece to have the locking implemented properly is to ensure that the
      lock is held for any other call path that may access the SMP context.
      This means user responses through mgmt.c, requests to elevate the
      security of a connection through hci_conn.c, as well as any deferred
      work through workqueues.
      
      This patch adds the necessary locking to all these other code paths that
      try to access the SMP context. Since mutual exclusion for the l2cap_chan
      access is now covered from all directions the patch also removes
      unnecessary HCI_CONN_LE_SMP_PEND flag (once we've acquired the chan lock
      we can simply check whether chan->smp is set to know if there's an SMP
      context).
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      fc75cc86
    • Johan Hedberg's avatar
      Bluetooth: Remove unnecessary deferred work for SMP key distribution · d6268e86
      Johan Hedberg authored
      Now that the identity address update happens through its own deferred
      work there's no need to have smp_distribute_keys anymore behind a second
      deferred work. This patch removes this extra construction and makes the
      code do direct calls to smp_distribute_keys() again.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d6268e86
    • Johan Hedberg's avatar
      Bluetooth: Move identity address update behind a workqueue · f3d82d0c
      Johan Hedberg authored
      The identity address update of all channels for an l2cap_conn needs to
      take the lock for each channel, i.e. it's safest to do this by a
      separate workqueue callback.
      
      Previously this was partially solved by moving the entire SMP key
      distribution behind a workqueue. However, if we want SMP context locking
      to be correct and safe we should always use the l2cap_chan lock when
      accessing it, meaning even smp_distribute_keys needs to take that lock
      which would once again create a dead lock when updating the identity
      address.
      
      The simplest way to solve this is to have l2cap_conn manage the deferred
      work which is what this patch does. A subsequent patch will remove the
      now unnecessary SMP key distribution work struct.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f3d82d0c
    • Johan Hedberg's avatar
      Bluetooth: Don't take any action in smp_resume_cb if not encrypted · 84bc0db5
      Johan Hedberg authored
      When smp_resume_cb is called if we're not encrypted (i.e. the callback
      wasn't called because the connection became encrypted) we shouldn't take
      any action at all. This patch moves also the security_timer cancellation
      behind this condition.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      84bc0db5
    • Johan Hedberg's avatar
      Bluetooth: Remove unnecessary checks after canceling SMP security timer · 1b0921d6
      Johan Hedberg authored
      The SMP security timer used to be able to modify the SMP context state
      but now days it simply calls hci_disconnect(). It is therefore
      unnecessary to have extra sanity checks for the SMP context after
      canceling the timer.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1b0921d6
    • Johan Hedberg's avatar
      Bluetooth: Add clarifying comment for LE CoC result value · 434714dc
      Johan Hedberg authored
      The "pending" L2CAP response value is not defined for LE CoC. This patch
      adds a clarifying comment to the code so that the reader will not think
      there is a bug in trying to use this value for LE CoC.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      434714dc
    • Johan Hedberg's avatar
      Bluetooth: Move clock offset reading into hci_disconnect() · 839035a7
      Johan Hedberg authored
      To give all hci_disconnect() users the advantage of getting the clock
      offset read automatically this patch moves the necessary code from
      hci_conn_timeout() into hci_disconnect(). This way we pretty much always
      update the clock offset when disconnecting.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      839035a7
    • Johan Hedberg's avatar
      Bluetooth: Use hci_disconnect() for mgmt_disconnect_device() · e3f2f92a
      Johan Hedberg authored
      There's no reason to custom build the HCI_Disconnect command in the
      Disconnect Device mgmt command handler. This patch updates the code to
      use hci_disconnect() instead.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e3f2f92a
    • Johan Hedberg's avatar
      Bluetooth: Update hci_disconnect() to return an error value · e3b679d5
      Johan Hedberg authored
      We'll soon use hci_disconnect() from places that are interested to know
      whether the hci_send_cmd() really succeeded or not. This patch updates
      hci_disconnect() to pass on any error returned from hci_send_cmd().
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e3b679d5
    • Johan Hedberg's avatar
      Bluetooth: Fix SMP error and response to be mutually exclusive · 9b7b18ef
      Johan Hedberg authored
      Returning failure from the SMP data parsing function will cause an
      immediate disconnect, making any attempts to send a response PDU futile.
      This patch updates the function to always either send a response or
      return an error, but never both at the same time:
      
      * In the case that HCI_LE_ENABLED is not set we want to send a Pairing Not
        Supported response but it is not required to force a disconnection, so
        do not set the error return in this case.
      
      * If we get garbage SMP data we can just fail with the handler function
        instead of also trying to send an SMP Failure PDU.
      
      * There's no reason to force a disconnection if we receive an unknown SMP
        command. Instead simply send a proper Command Not Supported SMP
        response.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9b7b18ef
    • Johan Hedberg's avatar
      Bluetooth: Remove unused l2cap_conn_shutdown API · b04afa0c
      Johan Hedberg authored
      Now that there are no more users of the l2cap_conn_shutdown API (since
      smp.c switched to using hci_disconnect) we can simply remove it along
      with all of it's l2cap_conn variables.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b04afa0c
    • Johan Hedberg's avatar
      Bluetooth: Use hci_disconnect for immediate disconnection from SMP · 1e91c29e
      Johan Hedberg authored
      Relying on the l2cap_conn_del procedure (triggered through the
      l2cap_conn_shutdown API) to get the connection disconnected is not
      reliable as it depends on all users releasing (through hci_conn_drop)
      and that there's at least one user (so hci_conn_drop is called at least
      one time).
      
      A much simpler and more reliable solution is to call hci_disconnect()
      directly from the SMP code when we want to disconnect. One side-effect
      this has is that it prevents any SMP Failure PDU from being sent before
      the disconnection, however neither one of the scenarios where
      l2cap_conn_shutdown was used really requires this.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1e91c29e