1. 03 7月, 2014 3 次提交
  2. 13 6月, 2014 1 次提交
  3. 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
  4. 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
  5. 27 3月, 2014 1 次提交
  6. 13 3月, 2014 1 次提交
  7. 15 2月, 2014 1 次提交
  8. 13 2月, 2014 6 次提交
  9. 19 1月, 2014 1 次提交
  10. 07 1月, 2014 1 次提交
    • J
      Bluetooth: Default to no security with L2CAP RAW sockets · cb6ca8e1
      Johan Hedberg 提交于
      L2CAP RAW sockets can be used for things which do not involve
      establishing actual connection oriented L2CAP channels. One example of
      such usage is the l2ping tool. The default security level for L2CAP
      sockets is LOW, which implies that for SSP based connection
      authentication is still requested (although with no MITM requirement),
      which is not what we want (or need) for things like l2ping. Therefore,
      default to one lower level, i.e. BT_SECURITY_SDP, for L2CAP RAW sockets
      in order not to trigger unwanted authentication requests.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cb6ca8e1
  11. 05 12月, 2013 8 次提交
  12. 22 10月, 2013 5 次提交
  13. 18 10月, 2013 1 次提交
  14. 17 10月, 2013 1 次提交
  15. 16 10月, 2013 5 次提交
  16. 15 10月, 2013 2 次提交
  17. 14 10月, 2013 1 次提交