1. 03 7月, 2014 2 次提交
  2. 13 6月, 2014 1 次提交
    • J
      Bluetooth: Fix deadlock in l2cap_conn_del() · 7ab56c3a
      Jukka Taimisto 提交于
      A deadlock occurs when PDU containing invalid SMP opcode is received on
      Security Manager Channel over LE link and conn->pending_rx_work worker
      has not run yet.
      
      When LE link is created l2cap_conn_ready() is called and before
      returning it schedules conn->pending_rx_work worker to hdev->workqueue.
      Incoming data to SMP fixed channel is handled by l2cap_recv_frame()
      which calls smp_sig_channel() to handle the SMP PDU. If
      smp_sig_channel() indicates failure l2cap_conn_del() is called to delete
      the connection. When deleting the connection, l2cap_conn_del() purges
      the pending_rx queue and calls flush_work() to wait for the
      pending_rx_work worker to complete.
      
      Since incoming data is handled by a worker running from the same
      workqueue as the pending_rx_work is being scheduled on, we will deadlock
      on waiting for pending_rx_work to complete.
      
      This patch fixes the deadlock by calling cancel_work_sync() instead of
      flush_work().
      Signed-off-by: NJukka Taimisto <jtt@codenomicon.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      7ab56c3a
  3. 31 5月, 2014 1 次提交
  4. 15 5月, 2014 1 次提交
  5. 13 3月, 2014 1 次提交
  6. 27 2月, 2014 3 次提交
  7. 26 2月, 2014 1 次提交
    • A
      Bluetooth: Fix NULL pointer dereference when sending data · ede81a2a
      Andrzej Kaczmarek 提交于
      When trying to allocate skb for new PDU, l2cap_chan is unlocked so we
      can sleep waiting for memory as otherwise there's possible deadlock as
      fixed in e454c844. However, in a6a5568c lock was moved from socket
      to channel level and it's no longer safe to just unlock and lock again
      without checking l2cap_chan state since channel can be disconnected
      when lock is not held.
      
      This patch adds missing checks for l2cap_chan state when returning from
      call which allocates skb.
      
      Scenario is easily reproducible by running rfcomm-tester in a loop.
      
      BUG: unable to handle kernel NULL pointer dereference at         (null)
      IP: [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth]
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 7 PID: 4038 Comm: krfcommd Not tainted 3.14.0-rc2+ #15
      Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A10 11/24/2011
      task: ffff8802bdd731c0 ti: ffff8801ec986000 task.ti: ffff8801ec986000
      RIP: 0010:[<ffffffffa0442169>]  [<ffffffffa0442169>] l2cap_do_send+0x29/0x120
      RSP: 0018:ffff8801ec987ad8  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff8800c5796800 RCX: 0000000000000000
      RDX: ffff880410e7a800 RSI: ffff8802b6c1da00 RDI: ffff8800c5796800
      RBP: ffff8801ec987af8 R08: 00000000000000c0 R09: 0000000000000300
      R10: 000000000000573b R11: 000000000000573a R12: ffff8802b6c1da00
      R13: 0000000000000000 R14: ffff8802b6c1da00 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88042dce0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000041257c000 CR4: 00000000000407e0
      Stack:
       ffff8801ec987d78 ffff8800c5796800 ffff8801ec987d78 0000000000000000
       ffff8801ec987ba8 ffffffffa0449e37 0000000000000004 ffff8801ec987af0
       ffff8801ec987d40 0000000000000282 0000000000000000 ffffffff00000004
      Call Trace:
       [<ffffffffa0449e37>] l2cap_chan_send+0xaa7/0x1120 [bluetooth]
       [<ffffffff81770100>] ? _raw_spin_unlock_bh+0x20/0x40
       [<ffffffffa045188b>] l2cap_sock_sendmsg+0xcb/0x110 [bluetooth]
       [<ffffffff81652b0f>] sock_sendmsg+0xaf/0xc0
       [<ffffffff810a8381>] ? update_curr+0x141/0x200
       [<ffffffff810a8961>] ? dequeue_entity+0x181/0x520
       [<ffffffff81652b60>] kernel_sendmsg+0x40/0x60
       [<ffffffffa04a8505>] rfcomm_send_frame+0x45/0x70 [rfcomm]
       [<ffffffff810766f0>] ? internal_add_timer+0x20/0x50
       [<ffffffffa04a8564>] rfcomm_send_cmd+0x34/0x60 [rfcomm]
       [<ffffffffa04a8605>] rfcomm_send_disc+0x75/0xa0 [rfcomm]
       [<ffffffffa04aacec>] rfcomm_run+0x8cc/0x1a30 [rfcomm]
       [<ffffffffa04aa420>] ? rfcomm_check_accept+0xc0/0xc0 [rfcomm]
       [<ffffffff8108e3a9>] kthread+0xc9/0xe0
       [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0
       [<ffffffff817795fc>] ret_from_fork+0x7c/0xb0
       [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0
      Code: 00 00 66 66 66 66 90 55 48 89 e5 48 83 ec 20 f6 05 d6 a3 02 00 04
      RIP  [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth]
       RSP <ffff8801ec987ad8>
      CR2: 0000000000000000
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ede81a2a
  8. 19 2月, 2014 2 次提交
  9. 15 2月, 2014 1 次提交
  10. 13 2月, 2014 12 次提交
  11. 12 12月, 2013 1 次提交
  12. 10 12月, 2013 1 次提交
  13. 06 12月, 2013 2 次提交
  14. 05 12月, 2013 11 次提交