1. 17 Oct, 2020 6 commits
  2. 01 Oct, 2020 5 commits
    • Sonny Sasaka's avatar
      Bluetooth: Handle Inquiry Cancel error after Inquiry Complete · 7f8a294b
      Sonny Sasaka authored
      [ Upstream commit adf1d692
      
       ]
      
      After sending Inquiry Cancel command to the controller, it is possible
      that Inquiry Complete event comes before Inquiry Cancel command complete
      event. In this case the Inquiry Cancel command will have status of
      Command Disallowed since there is no Inquiry session to be cancelled.
      This case should not be treated as error, otherwise we can reach an
      inconsistent state.
      
      Example of a btmon trace when this happened:
      
      < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0
      > HCI Event: Inquiry Complete (0x01) plen 1
              Status: Success (0x00)
      > HCI Event: Command Complete (0x0e) plen 4
            Inquiry Cancel (0x01|0x0002) ncmd 1
              Status: Command Disallowed (0x0c)
      Signed-off-by: default avatarSonny Sasaka <sonnysasaka@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7f8a294b
    • Howard Chung's avatar
      Bluetooth: L2CAP: handle l2cap config request during open state · b7d0ca71
      Howard Chung authored
      [ Upstream commit 96298f64
      
       ]
      
      According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5,
      the incoming L2CAP_ConfigReq should be handled during
      OPEN state.
      
      The section below shows the btmon trace when running
      L2CAP/COS/CFD/BV-12-C before and after this change.
      
      === Before ===
      ...
      > ACL Data RX: Handle 256 flags 0x02 dlen 12                #22
            L2CAP: Connection Request (0x02) ident 2 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      < ACL Data TX: Handle 256 flags 0x00 dlen 16                #23
            L2CAP: Connection Response (0x03) ident 2 len 8
              Destination CID: 64
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 256 flags 0x00 dlen 12                #24
            L2CAP: Configure Request (0x04) ident 2 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5      #25
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5      #26
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 16                #27
            L2CAP: Configure Request (0x04) ident 3 len 8
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00                                            ..
      < ACL Data TX: Handle 256 flags 0x00 dlen 18                #28
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      > HCI Event: Number of Completed Packets (0x13) plen 5      #29
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 14                #30
            L2CAP: Configure Response (0x05) ident 2 len 6
              Source CID: 64
              Flags: 0x0000
              Result: Success (0x0000)
      > ACL Data RX: Handle 256 flags 0x02 dlen 20                #31
            L2CAP: Configure Request (0x04) ident 3 len 12
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00 91 02 11 11                                ......
      < ACL Data TX: Handle 256 flags 0x00 dlen 14                #32
            L2CAP: Command Reject (0x01) ident 3 len 6
              Reason: Invalid CID in request (0x0002)
              Destination CID: 64
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5      #33
              Num handles: 1
              Handle: 256
              Count: 1
      ...
      === After ===
      ...
      > ACL Data RX: Handle 256 flags 0x02 dlen 12               #22
            L2CAP: Connection Request (0x02) ident 2 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      < ACL Data TX: Handle 256 flags 0x00 dlen 16               #23
            L2CAP: Connection Response (0x03) ident 2 len 8
              Destination CID: 64
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 256 flags 0x00 dlen 12               #24
            L2CAP: Configure Request (0x04) ident 2 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5     #25
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5     #26
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 16               #27
            L2CAP: Configure Request (0x04) ident 3 len 8
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00                                            ..
      < ACL Data TX: Handle 256 flags 0x00 dlen 18               #28
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      > HCI Event: Number of Completed Packets (0x13) plen 5     #29
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 14               #30
            L2CAP: Configure Response (0x05) ident 2 len 6
              Source CID: 64
              Flags: 0x0000
              Result: Success (0x0000)
      > ACL Data RX: Handle 256 flags 0x02 dlen 20               #31
            L2CAP: Configure Request (0x04) ident 3 len 12
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00 91 02 11 11                                .....
      < ACL Data TX: Handle 256 flags 0x00 dlen 18               #32
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      < ACL Data TX: Handle 256 flags 0x00 dlen 12               #33
            L2CAP: Configure Request (0x04) ident 3 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5     #34
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5     #35
              Num handles: 1
              Handle: 256
              Count: 1
      ...
      Signed-off-by: default avatarHoward Chung <howardchung@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7d0ca71
    • Alain Michaud's avatar
      Bluetooth: guard against controllers sending zero'd events · e500a986
      Alain Michaud authored
      [ Upstream commit 08bb4da9
      
       ]
      
      Some controllers have been observed to send zero'd events under some
      conditions.  This change guards against this condition as well as adding
      a trace to facilitate diagnosability of this condition.
      Signed-off-by: default avatarAlain Michaud <alainm@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e500a986
    • Hillf Danton's avatar
      Bluetooth: prefetch channel before killing sock · f708f141
      Hillf Danton authored
      [ Upstream commit 2a154903 ]
      
      Prefetch channel before killing sock in order to fix UAF like
      
       BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290 net/bluetooth/l2cap_sock.c:1212
       Read of size 8 at addr ffff8880944904a0 by task syz-fuzzer/9751
      
      Reported-by: syzbot+c3c5bdea7863886115dc@syzkaller.appspotmail.com
      Fixes: 6c08fc89
      
       ("Bluetooth: Fix refcount use-after-free issue")
      Cc: Manish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f708f141
    • Manish Mandlik's avatar
      Bluetooth: Fix refcount use-after-free issue · c6fed5fb
      Manish Mandlik authored
      [ Upstream commit 6c08fc89
      
       ]
      
      There is no lock preventing both l2cap_sock_release() and
      chan->ops->close() from running at the same time.
      
      If we consider Thread A running l2cap_chan_timeout() and Thread B running
      l2cap_sock_release(), expected behavior is:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
      
      where,
      sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks
      socket as SOCK_ZAPPED.
      
      In l2cap_sock_kill(), there is an "if-statement" that checks if both
      sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL
      and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is
      satisfied.
      
      In the race condition, following occurs:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
      In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and
      A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug.
      
      Similar condition occurs at other places where teardown/sock_kill is
      happening:
        l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        l2cap_sock_cleanup_listen()->l2cap_sock_kill()
      
      Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on
      l2cap channel to ensure that the socket is killed only after marked as
      zapped and orphan.
      Signed-off-by: default avatarManish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c6fed5fb
  3. 21 Aug, 2020 4 commits
  4. 20 Jun, 2020 1 commit
    • Hsin-Yu Chao's avatar
      Bluetooth: Add SCO fallback for invalid LMP parameters error · 5b0660c7
      Hsin-Yu Chao authored
      [ Upstream commit 56b5453a
      
       ]
      
      Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
      with invalid parameter at the first SCO request expecting AG to
      attempt another SCO request with the use of "safe settings" for
      given codec, base on section 5.7.1.2 of HFP 1.7 specification.
      
      This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
      to the SCO fallback case. Verified with below log:
      
      < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
              Handle: 256
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 13
              Setting: 0x0003
                Input Coding: Linear
                Input Data Format: 1's complement
                Input Sample Size: 8-bit
                # of bits padding at MSB: 0
                Air Coding Format: Transparent Data
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x0380
                3-EV3 may not be used
                2-EV5 may not be used
                3-EV5 may not be used
      > HCI Event: Command Status (0x0f) plen 4
            Setup Synchronous Connection (0x01|0x0028) ncmd 1
              Status: Success (0x00)
      > HCI Event: Number of Completed Packets (0x13) plen 5
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 1
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
              Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
              Handle: 0
              Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
              Link type: eSCO (0x02)
              Transmission interval: 0x00
              Retransmission window: 0x02
              RX packet length: 0
              TX packet length: 0
              Air mode: Transparent (0x03)
      < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
              Handle: 256
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 8
              Setting: 0x0003
                Input Coding: Linear
                Input Data Format: 1's complement
                Input Sample Size: 8-bit
                # of bits padding at MSB: 0
                Air Coding Format: Transparent Data
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x03c8
                EV3 may be used
                2-EV3 may not be used
                3-EV3 may not be used
                2-EV5 may not be used
                3-EV5 may not be used
      > HCI Event: Command Status (0x0f) plen 4
            Setup Synchronous Connection (0x01|0x0028) ncmd 1
              Status: Success (0x00)
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 5
      > HCI Event: Max Slots Change (0x1b) plen 3
              Handle: 256
              Max slots: 1
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
              Status: Success (0x00)
              Handle: 257
              Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
              Link type: eSCO (0x02)
              Transmission interval: 0x06
              Retransmission window: 0x04
              RX packet length: 30
              TX packet length: 30
              Air mode: Transparent (0x03)
      Signed-off-by: default avatarHsin-Yu Chao <hychao@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5b0660c7
  5. 13 Apr, 2020 1 commit
  6. 05 Feb, 2020 1 commit
  7. 12 Jan, 2020 2 commits
  8. 04 Jan, 2020 2 commits
  9. 25 Nov, 2019 1 commit
  10. 05 Oct, 2019 1 commit
  11. 04 Aug, 2019 4 commits
    • Szymon Janc's avatar
      Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug · 8f3286ca
      Szymon Janc authored
      commit 1d87b88b
      
       upstream.
      
      Microsoft Surface Precision Mouse provides bogus identity address when
      pairing. It connects with Static Random address but provides Public
      Address in SMP Identity Address Information PDU. Address has same
      value but type is different. Workaround this by dropping IRK if ID
      address discrepancy is detected.
      
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 75
              Role: Master (0x00)
              Peer address type: Random (0x01)
              Peer address: E0:52:33:93:3B:21 (Static)
              Connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Master clock accuracy: 0x00
      
      ....
      
      > ACL Data RX: Handle 75 flags 0x02 dlen 12
            SMP: Identity Address Information (0x09) len 7
              Address type: Public (0x00)
              Address: E0:52:33:93:3B:21
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Tested-by: default avatarMaarten Fonville <maarten.fonville@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461
      
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f3286ca
    • csonsino's avatar
      Bluetooth: validate BLE connection interval updates · 427d80d8
      csonsino authored
      [ Upstream commit c49a8682
      
       ]
      
      Problem: The Linux Bluetooth stack yields complete control over the BLE
      connection interval to the remote device.
      
      The Linux Bluetooth stack provides access to the BLE connection interval
      min and max values through /sys/kernel/debug/bluetooth/hci0/
      conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
      These values are used for initial BLE connections, but the remote device
      has the ability to request a connection parameter update. In the event
      that the remote side requests to change the connection interval, the Linux
      kernel currently only validates that the desired value is within the
      acceptable range in the Bluetooth specification (6 - 3200, corresponding to
      7.5ms - 4000ms). There is currently no validation that the desired value
      requested by the remote device is within the min/max limits specified in
      the conn_min_interval/conn_max_interval configurations. This essentially
      leads to Linux yielding complete control over the connection interval to
      the remote device.
      
      The proposed patch adds a verification step to the connection parameter
      update mechanism, ensuring that the desired value is within the min/max
      bounds of the current connection. If the desired value is outside of the
      current connection min/max values, then the connection parameter update
      request is rejected and the negative response is returned to the remote
      device. Recall that the initial connection is established using the local
      conn_min_interval/conn_max_interval values, so this allows the Linux
      administrator to retain control over the BLE connection interval.
      
      The one downside that I see is that the current default Linux values for
      conn_min_interval and conn_max_interval typically correspond to 30ms and
      50ms respectively. If this change were accepted, then it is feasible that
      some devices would no longer be able to negotiate to their desired
      connection interval values. This might be remedied by setting the default
      Linux conn_min_interval and conn_max_interval values to the widest
      supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
      behavior as the current implementation, where the remote device could
      request to change the connection interval value to any value that is
      permitted by the Bluetooth specification, and Linux would accept the
      desired value.
      Signed-off-by: default avatarCarey Sonsino <csonsino@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      427d80d8
    • Matias Karhumaa's avatar
      Bluetooth: Check state in l2cap_disconnect_rsp · 0a5e8c13
      Matias Karhumaa authored
      [ Upstream commit 28261da8
      
       ]
      
      Because of both sides doing L2CAP disconnection at the same time, it
      was possible to receive L2CAP Disconnection Response with CID that was
      already freed. That caused problems if CID was already reused and L2CAP
      Connection Request with same CID was sent out. Before this patch kernel
      deleted channel context regardless of the state of the channel.
      
      Example where leftover Disconnection Response (frame #402) causes local
      device to delete L2CAP channel which was not yet connected. This in
      turn confuses remote device's stack because same CID is re-used without
      properly disconnecting.
      
      Btmon capture before patch:
      ** snip **
      > ACL Data RX: Handle 43 flags 0x02 dlen 8                #394 [hci1] 10.748949
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8                #395 [hci1] 10.749062
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #396 [hci1] 10.749073
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5    #397 [hci1] 10.752391
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5    #398 [hci1] 10.753394
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #399 [hci1] 10.756499
            L2CAP: Disconnection Request (0x06) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #400 [hci1] 10.756548
            L2CAP: Disconnection Response (0x07) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #401 [hci1] 10.757459
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #402 [hci1] 10.759148
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o..   10.759447
      > HCI Event: Number of Completed Packets (0x13) plen 5    #403 [hci1] 10.759386
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #404 [hci1] 10.760397
            L2CAP: Connection Request (0x02) ident 27 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16               #405 [hci1] 10.760441
            L2CAP: Connection Response (0x03) ident 27 len 8
              Destination CID: 65
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27               #406 [hci1] 10.760449
            L2CAP: Configure Request (0x04) ident 19 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > HCI Event: Number of Completed Packets (0x13) plen 5    #407 [hci1] 10.761399
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 16               #408 [hci1] 10.762942
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Similar case after the patch:
      *snip*
      > ACL Data RX: Handle 43 flags 0x02 dlen 8            #22702 [hci0] 1664.411056
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8            #22703 [hci0] 1664.411136
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22704 [hci0] 1664.411143
            L2CAP: Disconnection Request (0x06) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22705 [hci0] 1664.414009
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22706 [hci0] 1664.415007
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22707 [hci0] 1664.418674
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22708 [hci0] 1664.418762
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22709 [hci0] 1664.421073
            L2CAP: Connection Request (0x02) ident 12 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22710 [hci0] 1664.421371
            L2CAP: Disconnection Response (0x07) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22711 [hci0] 1664.424082
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22712 [hci0] 1664.425040
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22713 [hci0] 1664.426103
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16           #22714 [hci0] 1664.426186
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27           #22715 [hci0] 1664.426196
            L2CAP: Configure Request (0x04) ident 13 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > ACL Data RX: Handle 43 flags 0x02 dlen 16           #22716 [hci0] 1664.428804
            L2CAP: Connection Response (0x03) ident 12 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Fix is to check that channel is in state BT_DISCONN before deleting the
      channel.
      
      This bug was found while fuzzing Bluez's OBEX implementation using
      Synopsys Defensics.
      Reported-by: default avatarMatti Kamunen <matti.kamunen@synopsys.com>
      Reported-by: default avatarAri Timonen <ari.timonen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a5e8c13
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: search for destination address in all peers · 09c3d402
      Josua Mayer authored
      [ Upstream commit b188b032
      
       ]
      
      Handle overlooked case where the target address is assigned to a peer
      and neither route nor gateway exist.
      
      For one peer, no checks are performed to see if it is meant to receive
      packets for a given address.
      
      As soon as there is a second peer however, checks are performed
      to deal with routes and gateways for handling complex setups with
      multiple hops to a target address.
      This logic assumed that no route and no gateway imply that the
      destination address can not be reached, which is false in case of a
      direct peer.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09c3d402
  12. 10 Jul, 2019 3 commits
  13. 22 Jun, 2019 1 commit
  14. 10 May, 2019 2 commits
  15. 03 Apr, 2019 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer · 99665dcf
      Marcel Holtmann authored
      commit 7c9cbd0b
      
       upstream.
      
      The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
      as length value. The opt->len however is in control over the remote user
      and can be used by an attacker to gain access beyond the bounds of the
      actual packet.
      
      To prevent any potential leak of heap memory, it is enough to check that
      the resulting len calculation after calling l2cap_get_conf_opt is not
      below zero. A well formed packet will always return >= 0 here and will
      end with the length value being zero after the last option has been
      parsed. In case of malformed packets messing with the opt->len field the
      length value will become negative. If that is the case, then just abort
      and ignore the option.
      
      In case an attacker uses a too short opt->len value, then garbage will
      be parsed, but that is protected by the unknown option handling and also
      the option parameter size checks.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99665dcf
    • Marcel Holtmann's avatar
      Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt · def5c1fb
      Marcel Holtmann authored
      commit af3d5d1c
      
       upstream.
      
      When doing option parsing for standard type values of 1, 2 or 4 octets,
      the value is converted directly into a variable instead of a pointer. To
      avoid being tricked into being a pointer, check that for these option
      types that sizes actually match. In L2CAP every option is fixed size and
      thus it is prudent anyway to ensure that the remote side sends us the
      right option size along with option paramters.
      
      If the option size is not matching the option type, then that option is
      silently ignored. It is a protocol violation and instead of trying to
      give the remote attacker any further hints just pretend that option is
      not present and proceed with the default values. Implementation
      following the specification and its qualification procedures will always
      use the correct size and thus not being impacted here.
      
      To keep the code readable and consistent accross all options, a few
      cosmetic changes were also required.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      def5c1fb
  16. 27 Mar, 2019 1 commit
  17. 12 Feb, 2019 1 commit
  18. 10 Nov, 2018 1 commit
    • Matias Karhumaa's avatar
      Bluetooth: SMP: fix crash in unpairing · 83e158f9
      Matias Karhumaa authored
      [ Upstream commit cb28c306 ]
      
      In case unpair_device() was called through mgmt interface at the same time
      when pairing was in progress, Bluetooth kernel module crash was seen.
      
      [  600.351225] general protection fault: 0000 [#1] SMP PTI
      [  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G           OE     4.19.0-rc1+ #1
      [  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
      [  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351287] RBP: ffffa9be839b3...
      83e158f9
  19. 19 Sep, 2018 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: hidp: Fix handling of strncpy for hid->name information · 64a6f7bf
      Marcel Holtmann authored
      [ Upstream commit b3cadaa4
      
       ]
      
      This fixes two issues with setting hid->name information.
      
        CC      net/bluetooth/hidp/core.o
      In function ‘hidp_setup_hid’,
          inlined from ‘hidp_session_dev_init’ at net/bluetooth/hidp/core.c:815:9,
          inlined from ‘hidp_session_new’ at net/bluetooth/hidp/core.c:953:8,
          inlined from ‘hidp_connection_add’ at net/bluetooth/hidp/core.c:1366:8:
      net/bluetooth/hidp/core.c:778:2: warning: ‘strncpy’ output may be truncated copying 127 bytes from a string of length 127 [-Wstringop-truncation]
        strncpy(hid->name, req->name, sizeof(req->name) - 1);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
        CC      net/bluetooth/hidp/core.o
      net/bluetooth/hidp/core.c: In function ‘hidp_setup_hid’:
      net/bluetooth/hidp/core.c:778:38: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Wsizeof-pointer-memaccess]
        strncpy(hid->name, req->name, sizeof(req->name));
                                            ^
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64a6f7bf