1. 15 Nov, 2013 1 commit
  2. 13 Nov, 2013 5 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix rejecting SMP security request in slave role · 86ca9eac
      Johan Hedberg authored
      The SMP security request is for a slave role device to request the
      master role device to initiate a pairing request. If we receive this
      command while we're in the slave role we should reject it appropriately.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      86ca9eac
    • Seung-Woo Kim's avatar
      Bluetooth: Fix crash in l2cap_chan_send after l2cap_chan_del · 31e8ce80
      Seung-Woo Kim authored
      Removing a bond and disconnecting from a specific remote device
      can cause l2cap_chan_send() is called after l2cap_chan_del() is
      called. This causes following crash.
      
      [ 1384.972086] Unable to handle kernel NULL pointer dereference at virtual address 00000008
      [ 1384.972090] pgd = c0004000
      [ 1384.972125] [00000008] *pgd=00000000
      [ 1384.972137] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [ 1384.972144] Modules linked in:
      [ 1384.972156] CPU: 0 PID: 841 Comm: krfcommd Not tainted 3.10.14-gdf22a71-dirty #435
      [ 1384.972162] task: df29a100 ti: df178000 task.ti: df178000
      [ 1384.972182] PC is at l2cap_create_basic_pdu+0x30/0x1ac
      [ 1384.972191] LR is at l2cap_chan_send+0x100/0x1d4
      [ 1384.972198] pc : [<c051d250>]    lr : [<c0521c78>]    psr: 40000113
      [ 1384.972198] sp : df179d40  ip : c083a010  fp : 00000008
      [ 1384.972202] r10: 00000004  r9 : 0000065a  r8 : 000003f5
      [ 1384.972206] r7 : 00000000  r6 : 00000000  r5 : df179e84  r4 : da557000
      [ 1384.972210] r3 : 00000000  r2 : 00000004  r1 : df179e84  r0 : 00000000
      [ 1384.972215] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [ 1384.972220] Control: 10c53c7d  Table: 5c8b004a  DAC: 00000015
      [ 1384.972224] Process krfcommd (pid: 841, stack limit = 0xdf178238)
      [ 1384.972229] Stack: (0xdf179d40 to 0xdf17a000)
      [ 1384.972238] 9d40: 00000000 da557000 00000004 df179e84 00000004 000003f5 0000065a 00000000
      [ 1384.972245] 9d60: 00000008 c0521c78 df179e84 da557000 00000004 da557204 de0c6800 df179e84
      [ 1384.972253] 9d80: da557000 00000004 da557204 c0526b7c 00000004 df724000 df179e84 00000004
      [ 1384.972260] 9da0: df179db0 df29a100 c083bc48 c045481c 00000001 00000000 00000000 00000000
      [ 1384.972267] 9dc0: 00000000 df29a100 00000000 00000000 00000000 00000000 df179e10 00000000
      [ 1384.972274] 9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [ 1384.972281] 9e00: 00000000 00000000 00000000 00000000 df179e4c c000ec80 c0b538c0 00000004
      [ 1384.972288] 9e20: df724000 df178000 00000000 df179e84 c0b538c0 00000000 df178000 c07f4570
      [ 1384.972295] 9e40: dcad9c00 df179e74 c07f4394 df179e60 df178000 00000000 df179e84 de247010
      [ 1384.972303] 9e60: 00000043 c0454dec 00000001 00000004 df315c00 c0530598 00000004 df315c0c
      [ 1384.972310] 9e80: ffffc32c 00000000 00000000 df179ea0 00000001 00000000 00000000 00000000
      [ 1384.972317] 9ea0: df179ebc 00000004 df315c00 c05df838 00000000 c0530810 c07d08c0 d7017303
      [ 1384.972325] 9ec0: 6ec245b9 00000000 df315c00 c0531b04 c07f3fe0 c07f4018 da67a300 df315c00
      [ 1384.972332] 9ee0: 00000000 c05334e0 df315c00 df315b80 df315c00 de0c6800 da67a300 00000000
      [ 1384.972339] 9f00: de0c684c c0533674 df204100 df315c00 df315c00 df204100 df315c00 c082b138
      [ 1384.972347] 9f20: c053385c c0533754 a0000113 df178000 00000001 c083bc48 00000000 c053385c
      [ 1384.972354] 9f40: 00000000 00000000 00000000 c05338c4 00000000 df9f0000 df9f5ee4 df179f6c
      [ 1384.972360] 9f60: df178000 c0049db4 00000000 00000000 c07f3ff8 00000000 00000000 00000000
      [ 1384.972368] 9f80: df179f80 df179f80 00000000 00000000 df179f90 df179f90 df9f5ee4 c0049cfc
      [ 1384.972374] 9fa0: 00000000 00000000 00000000 c000f168 00000000 00000000 00000000 00000000
      [ 1384.972381] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [ 1384.972388] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00010000 00000600
      [ 1384.972411] [<c051d250>] (l2cap_create_basic_pdu+0x30/0x1ac) from [<c0521c78>] (l2cap_chan_send+0x100/0x1d4)
      [ 1384.972425] [<c0521c78>] (l2cap_chan_send+0x100/0x1d4) from [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104)
      [ 1384.972440] [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104) from [<c045481c>] (sock_sendmsg+0xac/0xcc)
      [ 1384.972453] [<c045481c>] (sock_sendmsg+0xac/0xcc) from [<c0454dec>] (kernel_sendmsg+0x2c/0x34)
      [ 1384.972469] [<c0454dec>] (kernel_sendmsg+0x2c/0x34) from [<c0530598>] (rfcomm_send_frame+0x58/0x7c)
      [ 1384.972481] [<c0530598>] (rfcomm_send_frame+0x58/0x7c) from [<c0530810>] (rfcomm_send_ua+0x98/0xbc)
      [ 1384.972494] [<c0530810>] (rfcomm_send_ua+0x98/0xbc) from [<c0531b04>] (rfcomm_recv_disc+0xac/0x100)
      [ 1384.972506] [<c0531b04>] (rfcomm_recv_disc+0xac/0x100) from [<c05334e0>] (rfcomm_recv_frame+0x144/0x264)
      [ 1384.972519] [<c05334e0>] (rfcomm_recv_frame+0x144/0x264) from [<c0533674>] (rfcomm_process_rx+0x74/0xfc)
      [ 1384.972531] [<c0533674>] (rfcomm_process_rx+0x74/0xfc) from [<c0533754>] (rfcomm_process_sessions+0x58/0x160)
      [ 1384.972543] [<c0533754>] (rfcomm_process_sessions+0x58/0x160) from [<c05338c4>] (rfcomm_run+0x68/0x110)
      [ 1384.972558] [<c05338c4>] (rfcomm_run+0x68/0x110) from [<c0049db4>] (kthread+0xb8/0xbc)
      [ 1384.972576] [<c0049db4>] (kthread+0xb8/0xbc) from [<c000f168>] (ret_from_fork+0x14/0x2c)
      [ 1384.972586] Code: e3100004 e1a07003 e5946000 1a000057 (e5969008)
      [ 1384.972614] ---[ end trace 6170b7ce00144e8c ]---
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      31e8ce80
    • Seung-Woo Kim's avatar
      Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect · 8992da09
      Seung-Woo Kim authored
      L2CAP socket validates proper bdaddr_type for connect, so this
      patch fixes to set explictly bdaddr_type for RFCOMM connect.
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8992da09
    • Seung-Woo Kim's avatar
      Bluetooth: Fix RFCOMM bind fail for L2CAP sock · c507f138
      Seung-Woo Kim authored
      L2CAP socket bind checks its bdaddr type but RFCOMM kernel thread
      does not assign proper bdaddr type for L2CAP sock. This can cause
      that RFCOMM failure.
      Signed-off-by: default avatarSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c507f138
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with RFCOMM getsockopt operation · 60c7a3c9
      Marcel Holtmann authored
      The commit 94a86df0 seem to have
      uncovered a long standing bug that did not trigger so far.
      
      BUG: unable to handle kernel paging request at 00000009dd503502
      IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in: ath5k ath mac80211 cfg80211
      CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
      Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
      1202    12/22/2010
      task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
      RIP: 0010:[<ffffffff815b1868>]  [<ffffffff815b1868>]
      rfcomm_sock_getsockopt+0x128/0x200
      RSP: 0018:ffff88033046bed8  EFLAGS: 00010246
      RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
      RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
      RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
      R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
      R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
      FS:  00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
      Stack:
      ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
      0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
      0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
      Call Trace:
      [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
      [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
      [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
      Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
      f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
      2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
      RIP  [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
      RSP <ffff88033046bed8>
      CR2: 00000009dd503502
      
      It triggers in the following segment of the code:
      
      0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
      738
      739	static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
      740	{
      741		struct sock *sk = sock->sk;
      742		struct rfcomm_conninfo cinfo;
      743		struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
      744		int len, err = 0;
      745		u32 opt;
      746
      747		BT_DBG("sk %p", sk);
      
      The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
      but that socket of course does not contain the low-level connection
      details requested here.
      
      Tracking down the actual offending commit, it seems that this has been
      introduced when doing some L2CAP refactoring:
      
      commit 8c1d787b
      Author: Gustavo F. Padovan <padovan@profusion.mobi>
      Date:   Wed Apr 13 20:23:55 2011 -0300
      
      @@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
              struct sock *sk = sock->sk;
              struct sock *l2cap_sk;
              struct rfcomm_conninfo cinfo;
      +       struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
              int len, err = 0;
              u32 opt;
      
      @@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
      
                      l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
      
      -               cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
      -               memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
      +               cinfo.hci_handle = conn->hcon->handle;
      +               memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
      
      The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
      now causing a problem within getsocketopt() system call. To fix this,
      just re-introduce l2cap_sk and make sure the right socket is used for
      the low-level connection details.
      Reported-by: default avatarFabio Rossi <rossi.f@inwind.it>
      Reported-by: default avatarJanusz Dziedzic <janusz.dziedzic@gmail.com>
      Tested-by: default avatarJanusz Dziedzic <janusz.dziedzic@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      60c7a3c9
  3. 11 Nov, 2013 30 commits
  4. 09 Nov, 2013 2 commits
  5. 08 Nov, 2013 2 commits