1. 18 7月, 2016 1 次提交
  2. 09 4月, 2016 1 次提交
  3. 29 1月, 2016 2 次提交
  4. 21 10月, 2015 3 次提交
    • D
      Bluetooth: l2cap_disconnection_req priority over shutdown · 9f7378a9
      Dean Jenkins 提交于
      There is a L2CAP protocol race between the local peer and
      the remote peer demanding disconnection of the L2CAP link.
      
      When L2CAP ERTM is used, l2cap_sock_shutdown() can be called
      from userland to disconnect L2CAP. However, there can be a
      delay introduced by waiting for ACKs. During this waiting
      period, the remote peer may have sent a Disconnection Request.
      Therefore, recheck the shutdown status of the socket
      after waiting for ACKs because there is no need to do
      further processing if the connection has gone.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9f7378a9
    • D
      Bluetooth: Reorganize mutex lock in l2cap_sock_shutdown() · 04ba72e6
      Dean Jenkins 提交于
      This commit reorganizes the mutex lock and is now
      only protecting l2cap_chan_close(). This is now consistent
      with other places where l2cap_chan_close() is called.
      
      If a conn connection exists, call
      mutex_lock(&conn->chan_lock) before calling l2cap_chan_close()
      to ensure other L2CAP protocol operations do not interfere.
      
      Note that the conn structure has to be protected from being
      freed as it is possible for the connection to be disconnected
      whilst the locks are not held. This solution allows the mutex
      lock to be used even when the connection has just been
      disconnected.
      
      This commit also reduces the scope of chan locking.
      
      The only place where chan locking is needed is the call to
      l2cap_chan_close(chan, 0) which if necessary closes the channel.
      Therefore, move the l2cap_chan_lock(chan) and
      l2cap_chan_lock(chan) locking calls to around
      l2cap_chan_close(chan, 0).
      
      This allows __l2cap_wait_ack(sk, chan) to be called with no
      chan locks being held so L2CAP messaging over the ACL link
      can be done unimpaired.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      04ba72e6
    • D
      Bluetooth: Unwind l2cap_sock_shutdown() · e7456437
      Dean Jenkins 提交于
      l2cap_sock_shutdown() is designed to only action shutdown
      of the channel when shutdown is not already in progress.
      Therefore, reorganise the code flow by adding a goto
      to jump to the end of function handling when shutdown is
      already being actioned. This removes one level of code
      indentation and make the code more readable.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e7456437
  5. 23 7月, 2015 5 次提交
  6. 11 5月, 2015 1 次提交
  7. 31 3月, 2015 1 次提交
  8. 03 3月, 2015 1 次提交
  9. 24 1月, 2015 1 次提交
    • P
      Bluetooth: Fix nested sleeps · dfb2fae7
      Peter Hurley 提交于
      l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire
      sleeping locks. Since both wait loops and sleeping locks use
      task_struct.state to sleep and wake, the nested sleeping locks
      destroy the wait loop state.
      
      Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the
      wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function
      to be specified; in this case, the predefined scheduler function,
      woken_wake_function(). This wait construct ensures wakeups will
      not be missed without requiring the wait loop to set the
      task state before condition evaluation. How this works:
      
       CPU 0                            |  CPU 1
                                        |
                                        | is <condition> set?
                                        | no
      set <condition>                   |
                                        |
      wake_up_interruptible             |
        woken_wake_function             |
          set WQ_FLAG_WOKEN             |
          try_to_wake_up                |
                                        | wait_woken
                                        |   set TASK_INTERRUPTIBLE
                                        |   WQ_FLAG_WOKEN? yes
                                        |   set TASK_RUNNING
                                        |
                                        | - loop -
      				  |
      				  | is <condition> set?
                                        | yes - exit wait loop
      
      Fixes "do not call blocking ops when !TASK_RUNNING" warnings
      in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept().
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      dfb2fae7
  10. 12 1月, 2015 1 次提交
  11. 10 12月, 2014 2 次提交
  12. 15 11月, 2014 1 次提交
  13. 13 11月, 2014 3 次提交
    • J
      Bluetooth: Fix L2CAP nesting level initialization location · ff714119
      Johan Hedberg 提交于
      There's no reason why all users of L2CAP would need to worry about
      initializing chan->nesting to L2CAP_NESTING_NORMAL (which is important
      since 0 is the same as NESTING_SMP). This patch moves the initialization
      to the common place that's used to create all new channels, i.e. the
      l2cap_chan_create() function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ff714119
    • J
      Bluetooth: Fix L2CAP socket lock nesting level · 3b2ab39e
      Johan Hedberg 提交于
      The teardown callback for L2CAP channels is problematic in that it is
      explicitly called for all types of channels from l2cap_chan_del(),
      meaning it's not possible to hard-code a nesting level when taking the
      socket lock. The simplest way to have a correct nesting level for the
      socket locking is to use the same value as for the chan. This also means
      that the other places trying to lock parent sockets need to be update to
      use the chan value (since L2CAP_NESTING_PARENT is defined as 2 whereas
      SINGLE_DEPTH_NESTING has the value 1).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3b2ab39e
    • J
      Bluetooth: Use proper nesting annotation for l2cap_chan lock · abe84903
      Johan Hedberg 提交于
      By default lockdep considers all L2CAP channels equal. This would mean
      that we get warnings if a channel is locked when another one's lock is
      tried to be acquired in the same thread. This kind of inter-channel
      locking dependencies exist in the form of parent-child channels as well
      as any channel wishing to elevate the security by requesting procedures
      on the SMP channel.
      
      To eliminate the chance for these lockdep warnings we introduce a
      nesting level for each channel and use that when acquiring the channel
      lock. For now there exists the earlier mentioned three identified
      categories: SMP, "normal" channels and parent channels (i.e. those in
      BT_LISTEN state). The nesting level is defined as atomic_t since we need
      access to it before the lock is actually acquired.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      abe84903
  14. 12 11月, 2014 1 次提交
    • J
      Bluetooth: Fix l2cap_sock_teardown_cb lockdep warning · f0356704
      Johan Hedberg 提交于
      Any code calling bt_accept_dequeue() to get a new child socket from a
      server socket should use lock_sock_nested to avoid lockdep warnings due
      to the parent and child sockets being locked at the same time. The
      l2cap_sock_accept() function is already doing this correctly but a
      second place calling bt_accept_dequeue() is the code path from
      l2cap_sock_teardown_cb() that calls l2cap_sock_cleanup_listen().
      
      This patch fixes the proper nested locking annotation and thereby avoids
      the following style of lockdep warning.
      
      [  +0.000224] [ INFO: possible recursive locking detected ]
      [  +0.000222] 3.17.0+ #1153 Not tainted
      [  +0.000130] ---------------------------------------------
      [  +0.000227] l2cap-tester/562 is trying to acquire lock:
      [  +0.000210]  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<c1393f47>] bt_accept_dequeue+0x68/0x11b
      [  +0.000467]
      but task is already holding lock:
      [  +0.000186]  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<c13b949a>] lock_sock+0xa/0xc
      [  +0.000421]
      other info that might help us debug this:
      [  +0.000199]  Possible unsafe locking scenario:
      
      [  +0.000117]        CPU0
      [  +0.000000]        ----
      [  +0.000000]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      [  +0.000000]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      [  +0.000000]
       *** DEADLOCK ***
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f0356704
  15. 09 9月, 2014 1 次提交
    • J
      Bluetooth: Fix hci_conn reference counting for fixed channels · c16900cf
      Johan Hedberg 提交于
      Now that SMP has been converted to use fixed channels we've got a bit of
      a problem with the hci_conn reference counting. So far the L2CAP code
      has kept a reference for each L2CAP channel that was notified of the
      connection. With SMP however this would mean that the connection is
      never dropped even though there are no other users of it. Furthermore,
      SMP already does its own hci_conn reference counting internally,
      starting from a security or pairing request and ending with the key
      distribution.
      
      This patch makes L2CAP fixed channels default to the L2CAP core not
      keeping a hci_conn reference for them. A new FLAG_HOLD_HCI_CONN flag is
      added so that L2CAP users can declare an exception to this rule and hold
      a reference even for their fixed channels. One such exception is the
      L2CAP socket layer which does want a reference for each socket (e.g. an
      ATT socket which uses a fixed channel).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c16900cf
  16. 14 8月, 2014 2 次提交
  17. 18 7月, 2014 1 次提交
  18. 17 7月, 2014 2 次提交
    • J
      Bluetooth: Pass initiator/acceptor information to hci_conn_security() · e7cafc45
      Johan Hedberg 提交于
      We're interested in whether an authentication request is because of a
      remote or local action. So far hci_conn_security() has been used both
      for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect
      requests) so without some modifications it cannot know which peer is
      responsible for requesting authentication.
      
      This patch adds a new "bool initiator" parameter to hci_conn_security()
      to indicate which side is responsible for the request and updates the
      current users to pass this information correspondingly.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e7cafc45
    • V
      Bluetooth: never linger on process exit · 093facf3
      Vladimir Davydov 提交于
      If the current process is exiting, lingering on socket close will make
      it unkillable, so we should avoid it.
      
      Reproducer:
      
        #include <sys/types.h>
        #include <sys/socket.h>
      
        #define BTPROTO_L2CAP   0
        #define BTPROTO_SCO     2
        #define BTPROTO_RFCOMM  3
      
        int main()
        {
                int fd;
                struct linger ling;
      
                fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
                //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
                //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);
      
                ling.l_onoff = 1;
                ling.l_linger = 1000000000;
                setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
      
                return 0;
        }
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      093facf3
  19. 03 7月, 2014 5 次提交
  20. 13 6月, 2014 1 次提交
  21. 02 6月, 2014 1 次提交
    • J
      Bluetooth: Fix L2CAP deadlock · 8a96f3cd
      Jukka Taimisto 提交于
      -[0x01 Introduction
      
      We have found a programming error causing a deadlock in Bluetooth subsystem
      of Linux kernel. The problem is caused by missing release_sock() call when
      L2CAP connection creation fails due full accept queue.
      
      The issue can be reproduced with 3.15-rc5 kernel and is also present in
      earlier kernels.
      
      -[0x02 Details
      
      The problem occurs when multiple L2CAP connections are created to a PSM which
      contains listening socket (like SDP) and left pending, for example,
      configuration (the underlying ACL link is not disconnected between
      connections).
      
      When L2CAP connection request is received and listening socket is found the
      l2cap_sock_new_connection_cb() function (net/bluetooth/l2cap_sock.c) is called.
      This function locks the 'parent' socket and then checks if the accept queue
      is full.
      
      1178         lock_sock(parent);
      1179
      1180         /* Check for backlog size */
      1181         if (sk_acceptq_is_full(parent)) {
      1182                 BT_DBG("backlog full %d", parent->sk_ack_backlog);
      1183                 return NULL;
      1184         }
      
      If case the accept queue is full NULL is returned, but the 'parent' socket
      is not released. Thus when next L2CAP connection request is received the code
      blocks on lock_sock() since the parent is still locked.
      
      Also note that for connections already established and waiting for
      configuration to complete a timeout will occur and l2cap_chan_timeout()
      (net/bluetooth/l2cap_core.c) will be called. All threads calling this
      function will also be blocked waiting for the channel mutex since the thread
      which is waiting on lock_sock() alread holds the channel mutex.
      
      We were able to reproduce this by sending continuously L2CAP connection
      request followed by disconnection request containing invalid CID. This left
      the created connections pending configuration.
      
      After the deadlock occurs it is impossible to kill bluetoothd, btmon will not
      get any more data etc. requiring reboot to recover.
      
      -[0x03 Fix
      
      Releasing the 'parent' socket when l2cap_sock_new_connection_cb() returns NULL
      seems to fix the issue.
      Signed-off-by: NJukka Taimisto <jtt@codenomicon.com>
      Reported-by: NTommi Mäkilä <tmakila@codenomicon.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      8a96f3cd
  22. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  23. 27 3月, 2014 1 次提交
  24. 13 3月, 2014 1 次提交