1. 15 Nov, 2013 2 commits
  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 1 commit
    • John Fastabend's avatar
      ixgbe: deleting dfwd stations out of order can cause null ptr deref · 51f3773b
      John Fastabend authored
      The number of stations in use is kept in the num_rx_pools counter
      in the ixgbe_adapter structure. This is in turn used by the queue
      allocation scheme to determine how many queues are needed to support
      the number of pools in use with the current feature set.
      
      This works as long as the pools are added and destroyed in order
      because (num_rx_pools * queues_per_pool) is equal to the last
      queue in use by a pool. But as soon as you delete a pool out of
      order this is no longer the case. So the above multiplication
      allocates to few queues and a pool may reference a ring that has
      not been allocated/initialized.
      
      To resolve use the bit mask of in use pools to determine the final
      pool being used and allocate enough queues so that we don't
      inadvertently remove its queues.
      
      # ip link add link eth2 \
      	numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
      # ip link set dev macvlan0 up
      # ip link add link eth2 \
      	numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
      # ip link set dev macvlan1 up
      # for i in {0..100}; do
        ip link set dev macvlan0 down; ip link set dev macvlan0 up;
        done;
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51f3773b