1. 20 9月, 2016 14 次提交
  2. 26 8月, 2016 2 次提交
  3. 24 8月, 2016 2 次提交
    • D
      Bluetooth: split sk_filter in l2cap_sock_recv_cb · dbb50887
      Daniel Borkmann 提交于
      During an audit for sk_filter(), we found that rx_busy_skb handling
      in l2cap_sock_recv_cb() and l2cap_sock_recvmsg() looks not quite as
      intended.
      
      The assumption from commit e328140f ("Bluetooth: Use event-driven
      approach for handling ERTM receive buffer") is that errors returned
      from sock_queue_rcv_skb() are due to receive buffer shortage. However,
      nothing should prevent doing a setsockopt() with SO_ATTACH_FILTER on
      the socket, that could drop some of the incoming skbs when handled in
      sock_queue_rcv_skb().
      
      In that case sock_queue_rcv_skb() will return with -EPERM, propagated
      from sk_filter() and if in L2CAP_MODE_ERTM mode, wrong assumption was
      that we failed due to receive buffer being full. From that point onwards,
      due to the to-be-dropped skb being held in rx_busy_skb, we cannot make
      any forward progress as rx_busy_skb is never cleared from l2cap_sock_recvmsg(),
      due to the filter drop verdict over and over coming from sk_filter().
      Meanwhile, in l2cap_sock_recv_cb() all new incoming skbs are being
      dropped due to rx_busy_skb being occupied.
      
      Instead, just use __sock_queue_rcv_skb() where an error really tells that
      there's a receive buffer issue. Split the sk_filter() and enable it for
      non-segmented modes at queuing time since at this point in time the skb has
      already been through the ERTM state machine and it has been acked, so dropping
      is not allowed. Instead, for ERTM and streaming mode, call sk_filter() in
      l2cap_data_rcv() so the packet can be dropped before the state machine sees it.
      
      Fixes: e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      dbb50887
    • F
      Bluetooth: Fix memory leak at end of hci requests · 9afee949
      Frederic Dalleau 提交于
      In hci_req_sync_complete the event skb is referenced in hdev->req_skb.
      It is used (via hci_req_run_skb) from either __hci_cmd_sync_ev which will
      pass the skb to the caller, or __hci_req_sync which leaks.
      
      unreferenced object 0xffff880005339a00 (size 256):
        comm "kworker/u3:1", pid 1011, jiffies 4294671976 (age 107.389s)
        backtrace:
          [<ffffffff818d89d9>] kmemleak_alloc+0x49/0xa0
          [<ffffffff8116bba8>] kmem_cache_alloc+0x128/0x180
          [<ffffffff8167c1df>] skb_clone+0x4f/0xa0
          [<ffffffff817aa351>] hci_event_packet+0xc1/0x3290
          [<ffffffff8179a57b>] hci_rx_work+0x18b/0x360
          [<ffffffff810692ea>] process_one_work+0x14a/0x440
          [<ffffffff81069623>] worker_thread+0x43/0x4d0
          [<ffffffff8106ead4>] kthread+0xc4/0xe0
          [<ffffffff818dd38f>] ret_from_fork+0x1f/0x40
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@collabora.co.uk>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9afee949
  4. 18 7月, 2016 2 次提交
  5. 13 7月, 2016 2 次提交
    • J
      Bluetooth: Increment management interface revision · 87510973
      Johan Hedberg 提交于
      Increment the mgmt revision due to the recently added new
      reason code for the Disconnected event.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      87510973
    • S
      Bluetooth: Add Authentication Failed reason to Disconnected Mgmt event · 160b9251
      Szymon Janc 提交于
      If link is disconnected due to Authentication Failure (PIN or Key
      Missing status) userspace will be notified about this with proper error
      code. Many LE profiles define "PIN or Key Missing" status as indication
      of remote lost bond so this allows userspace to take action on this.
      
      @ Device Connected: 88:63:DF:88:0E:83 (1) flags 0x0000
              02 01 1a 05 03 0a 18 0d 18 0b 09 48 65 61 72 74  ...........Heart
              20 52 61 74 65                                    Rate
      > HCI Event: Command Status (0x0f) plen 4
            LE Read Remote Used Features (0x08|0x0016) ncmd 1
              Status: Success (0x00)
      > ACL Data RX: Handle 3585 flags 0x02 dlen 11
            ATT: Read By Group Type Request (0x10) len 6
              Handle range: 0x0001-0xffff
              Attribute group type: Primary Service (0x2800)
      > HCI Event: LE Meta Event (0x3e) plen 12
            LE Read Remote Used Features (0x04)
              Status: Success (0x00)
              Handle: 3585
              Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                LE Encryption
      < HCI Command: LE Start Encryption (0x08|0x0019) plen 28
              Handle: 3585
              Random number: 0x0000000000000000
              Encrypted diversifier: 0x0000
              Long term key: 26201cd479a0921b6f949f0b1fa8dc82
      > HCI Event: Command Status (0x0f) plen 4
            LE Start Encryption (0x08|0x0019) ncmd 1
              Status: Success (0x00)
      > HCI Event: Encryption Change (0x08) plen 4
              Status: PIN or Key Missing (0x06)
              Handle: 3585
              Encryption: Disabled (0x00)
      < HCI Command: Disconnect (0x01|0x0006) plen 3
              Handle: 3585
              Reason: Authentication Failure (0x05)
      > HCI Event: Command Status (0x0f) plen 4
            Disconnect (0x01|0x0006) ncmd 1
              Status: Success (0x00)
      > HCI Event: Disconnect Complete (0x05) plen 4
              Status: Success (0x00)
              Handle: 3585
              Reason: Connection Terminated By Local Host (0x16)
      @ Device Disconnected: 88:63:DF:88:0E:83 (1) reason 4
      
      @ Device Connected: C4:43:8F:A3:4D:83 (0) flags 0x0000
              08 09 4e 65 78 75 73 20 35                       ..Nexus 5
      > HCI Event: Command Status (0x0f) plen 4
            Authentication Requested (0x01|0x0011) ncmd 1
              Status: Success (0x00)
      > HCI Event: Link Key Request (0x17) plen 6
              Address: C4:43:8F:A3:4D:83 (LG Electronics)
      < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
              Address: C4:43:8F:A3:4D:83 (LG Electronics)
              Link key: 080812e4aa97a863d11826f71f65a933
      > HCI Event: Command Complete (0x0e) plen 10
            Link Key Request Reply (0x01|0x000b) ncmd 1
              Status: Success (0x00)
              Address: C4:43:8F:A3:4D:83 (LG Electronics)
      > HCI Event: Auth Complete (0x06) plen 3
              Status: PIN or Key Missing (0x06)
              Handle: 75
      @ Authentication Failed: C4:43:8F:A3:4D:83 (0) status 0x05
      < HCI Command: Disconnect (0x01|0x0006) plen 3
              Handle: 75
              Reason: Remote User Terminated Connection (0x13)
      > HCI Event: Command Status (0x0f) plen 4
            Disconnect (0x01|0x0006) ncmd 1
              Status: Success (0x00)
      > HCI Event: Disconnect Complete (0x05) plen 4
              Status: Success (0x00)
              Handle: 75
              Reason: Connection Terminated By Local Host (0x16)
      @ Device Disconnected: C4:43:8F:A3:4D:83 (0) reason 4
      Signed-off-by: NSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      160b9251
  6. 10 7月, 2016 3 次提交
  7. 08 7月, 2016 3 次提交
    • D
      Bluetooth: Fix hci_sock_recvmsg return value · 83871f8c
      Denis Kenzior 提交于
      If recvmsg is called with a destination buffer that is too small to
      receive the contents of skb in its entirety, the return value from
      recvmsg was inconsistent with common SOCK_SEQPACKET or SOCK_DGRAM
      semantics.
      
      If destination buffer provided by userspace is too small (e.g. len <
      copied), then MSG_TRUNC flag is set and copied is returned.  Instead, it
      should return the length of the message, which is consistent with how
      other datagram based sockets act.  Quoting 'man recv':
      
      "All  three calls return the length of the message on successful comple‐
      tion.  If a message is too long to fit in the supplied  buffer,  excess
      bytes  may  be discarded depending on the type of socket the message is
      received from."
      
      and
      
      "MSG_TRUNC (since Linux 2.2)
      
          For   raw   (AF_PACKET),   Internet   datagram   (since    Linux
          2.4.27/2.6.8),  netlink  (since Linux 2.6.22), and UNIX datagram
          (since Linux 3.4) sockets: return the real length of the packet
          or datagram, even when it was longer than the passed buffer."
      Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      83871f8c
    • D
      Bluetooth: Fix bt_sock_recvmsg return value · b5f34f94
      Denis Kenzior 提交于
      If recvmsg is called with a destination buffer that is too small to
      receive the contents of skb in its entirety, the return value from
      recvmsg was inconsistent with common SOCK_SEQPACKET or SOCK_DGRAM
      semantics.
      
      If destination buffer provided by userspace is too small (e.g. len <
      copied), then MSG_TRUNC flag is set and copied is returned.  Instead, it
      should return the length of the message, which is consistent with how
      other datagram based sockets act.  Quoting 'man recv':
      
      "All  three calls return the length of the message on successful comple‐
      tion.  If a message is too long to fit in the supplied  buffer,  excess
      bytes  may  be discarded depending on the type of socket the message is
      received from."
      
      and
      
      "MSG_TRUNC (since Linux 2.2)
      
          For   raw   (AF_PACKET),   Internet   datagram   (since    Linux
          2.4.27/2.6.8),  netlink  (since Linux 2.6.22), and UNIX datagram
          (since Linux 3.4) sockets: return the real length of the packet
          or datagram, even when it was longer than the passed buffer."
      Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b5f34f94
    • A
      Bluetooth: Switch SMP to crypto_cipher_encrypt_one() · a4770e11
      Andy Lutomirski 提交于
      SMP does ECB crypto on stack buffers.  This is complicated and
      fragile, and it will not work if the stack is virtually allocated.
      
      Switch to the crypto_cipher interface, which is simpler and safer.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a4770e11
  8. 10 6月, 2016 1 次提交
  9. 08 6月, 2016 1 次提交
  10. 13 5月, 2016 1 次提交
    • J
      Bluetooth: fix power_on vs close race · bf389cab
      Jiri Slaby 提交于
      With all the latest fixes applied, I am still able to reproduce this
      (and other) warning(s):
      WARNING: CPU: 1 PID: 19684 at ../kernel/workqueue.c:4092 destroy_workqueue+0x70a/0x770()
      ...
      Call Trace:
       [<ffffffff819fee81>] ? dump_stack+0xb3/0x112
       [<ffffffff8117377e>] ? warn_slowpath_common+0xde/0x140
       [<ffffffff811ce68a>] ? destroy_workqueue+0x70a/0x770
       [<ffffffff811739ae>] ? warn_slowpath_null+0x2e/0x40
       [<ffffffff811ce68a>] ? destroy_workqueue+0x70a/0x770
       [<ffffffffa0c944c9>] ? hci_unregister_dev+0x2a9/0x720 [bluetooth]
       [<ffffffffa0b301db>] ? vhci_release+0x7b/0xf0 [hci_vhci]
       [<ffffffffa0b30160>] ? vhci_flush+0x50/0x50 [hci_vhci]
       [<ffffffff8117cd73>] ? do_exit+0x863/0x2b90
      
      This is due to race present in the hci_unregister_dev path.
      hdev->power_on work races with hci_dev_do_close. One tries to open,
      the other tries to close, leading to warning like the above. (Another
      example is a warning in kobject_get or kobject_put depending on who
      wins the race.)
      
      Fix this by switching those two racers to ensure hdev->power_on never
      triggers while hci_dev_do_close is in progress.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      bf389cab
  11. 05 5月, 2016 1 次提交
  12. 26 4月, 2016 1 次提交
    • G
      Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address · 55441070
      Glenn Ruben Bakke 提交于
      The memcpy of ipv6 header destination address to the skb control block
      (sbk->cb) in header_create() results in currupted memory when bt_xmit()
      is issued. The skb->cb is "released" in the return of header_create()
      making room for lower layer to minipulate the skb->cb.
      
      The value retrieved in bt_xmit is not persistent across header creation
      and sending, and the lower layer will overwrite portions of skb->cb,
      making the copied destination address wrong.
      
      The memory corruption will lead to non-working multicast as the first 4
      bytes of the copied destination address is replaced by a value that
      resolves into a non-multicast prefix.
      
      This fix removes the dependency on the skb control block between header
      creation and send, by moving the destination address memcpy to the send
      function path (setup_create, which is called from bt_xmit).
      Signed-off-by: NGlenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org # 4.5+
      55441070
  13. 14 4月, 2016 1 次提交
  14. 13 4月, 2016 1 次提交
    • A
      6lowpan: change naming for lowpan private data · 2e4d60cb
      Alexander Aring 提交于
      This patch changes the naming for interface private data for lowpan
      intefaces. The current private data scheme is:
      
      -------------------------------------------------
      |    6LoWPAN Generic   |    LinkLayer 6LoWPAN   |
      -------------------------------------------------
      
      the current naming schemes are:
      
      - 6LoWPAN Generic:
        - lowpan_priv
      - LinkLayer 6LoWPAN:
        - BTLE
          - lowpan_dev
        - 802.15.4:
          - lowpan_dev_info
      
      the new naming scheme with this patch will be:
      
      - 6LoWPAN Generic:
        - lowpan_dev
      - LinkLayer 6LoWPAN:
        - BTLE
          - lowpan_btle_dev
        - 802.15.4:
          - lowpan_802154_dev
      Signed-off-by: NAlexander Aring <aar@pengutronix.de>
      Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com>
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2e4d60cb
  15. 09 4月, 2016 3 次提交
  16. 11 3月, 2016 2 次提交