22 Aug, 2018
1 commit
-
commit 4e1a720d0312fd510699032c7694a362a010170f upstream.
slub debug reported:
[ 440.648642] =============================================================================
[ 440.648649] BUG kmalloc-1024 (Tainted: G BU O ): Poison overwritten
[ 440.648651] -----------------------------------------------------------------------------[ 440.648655] INFO: 0xe70f4bec-0xe70f4bec. First byte 0x6a instead of 0x6b
[ 440.648665] INFO: Allocated in sk_prot_alloc+0x6b/0xc6 age=33155 cpu=1 pid=1047
[ 440.648671] ___slab_alloc.constprop.24+0x1fc/0x292
[ 440.648675] __slab_alloc.isra.18.constprop.23+0x1c/0x25
[ 440.648677] __kmalloc+0xb6/0x17f
[ 440.648680] sk_prot_alloc+0x6b/0xc6
[ 440.648683] sk_alloc+0x1e/0xa1
[ 440.648700] sco_sock_alloc.constprop.6+0x26/0xaf [bluetooth]
[ 440.648716] sco_connect_cfm+0x166/0x281 [bluetooth]
[ 440.648731] hci_conn_request_evt.isra.53+0x258/0x281 [bluetooth]
[ 440.648746] hci_event_packet+0x28b/0x2326 [bluetooth]
[ 440.648759] hci_rx_work+0x161/0x291 [bluetooth]
[ 440.648764] process_one_work+0x163/0x2b2
[ 440.648767] worker_thread+0x1a9/0x25c
[ 440.648770] kthread+0xf8/0xfd
[ 440.648774] ret_from_fork+0x2e/0x38
[ 440.648779] INFO: Freed in __sk_destruct+0xd3/0xdf age=3815 cpu=1 pid=1047
[ 440.648782] __slab_free+0x4b/0x27a
[ 440.648784] kfree+0x12e/0x155
[ 440.648787] __sk_destruct+0xd3/0xdf
[ 440.648790] sk_destruct+0x27/0x29
[ 440.648793] __sk_free+0x75/0x91
[ 440.648795] sk_free+0x1c/0x1e
[ 440.648810] sco_sock_kill+0x5a/0x5f [bluetooth]
[ 440.648825] sco_conn_del+0x8e/0xba [bluetooth]
[ 440.648840] sco_disconn_cfm+0x3a/0x41 [bluetooth]
[ 440.648855] hci_event_packet+0x45e/0x2326 [bluetooth]
[ 440.648868] hci_rx_work+0x161/0x291 [bluetooth]
[ 440.648872] process_one_work+0x163/0x2b2
[ 440.648875] worker_thread+0x1a9/0x25c
[ 440.648877] kthread+0xf8/0xfd
[ 440.648880] ret_from_fork+0x2e/0x38
[ 440.648884] INFO: Slab 0xf4718580 objects=27 used=27 fp=0x (null) flags=0x40008100
[ 440.648886] INFO: Object 0xe70f4b88 @offset=19336 fp=0xe70f54f8When KASAN was enabled, it reported:
[ 210.096613] ==================================================================
[ 210.096634] BUG: KASAN: use-after-free in ex_handler_refcount+0x5b/0x127
[ 210.096641] Write of size 4 at addr ffff880107e17160 by task kworker/u9:1/2040[ 210.096651] CPU: 1 PID: 2040 Comm: kworker/u9:1 Tainted: G U O 4.14.47-20180606+ #2
[ 210.096654] Hardware name: , BIOS 2017.01-00087-g43e04de 08/30/2017
[ 210.096693] Workqueue: hci0 hci_rx_work [bluetooth]
[ 210.096698] Call Trace:
[ 210.096711] dump_stack+0x46/0x59
[ 210.096722] print_address_description+0x6b/0x23b
[ 210.096729] ? ex_handler_refcount+0x5b/0x127
[ 210.096736] kasan_report+0x220/0x246
[ 210.096744] ex_handler_refcount+0x5b/0x127
[ 210.096751] ? ex_handler_clear_fs+0x85/0x85
[ 210.096757] fixup_exception+0x8c/0x96
[ 210.096766] do_trap+0x66/0x2c1
[ 210.096773] do_error_trap+0x152/0x180
[ 210.096781] ? fixup_bug+0x78/0x78
[ 210.096817] ? hci_debugfs_create_conn+0x244/0x26a [bluetooth]
[ 210.096824] ? __schedule+0x113b/0x1453
[ 210.096830] ? sysctl_net_exit+0xe/0xe
[ 210.096837] ? __wake_up_common+0x343/0x343
[ 210.096843] ? insert_work+0x107/0x163
[ 210.096850] invalid_op+0x1b/0x40
[ 210.096888] RIP: 0010:hci_debugfs_create_conn+0x244/0x26a [bluetooth]
[ 210.096892] RSP: 0018:ffff880094a0f970 EFLAGS: 00010296
[ 210.096898] RAX: 0000000000000000 RBX: ffff880107e170e8 RCX: ffff880107e17160
[ 210.096902] RDX: 000000000000002f RSI: ffff88013b80ed40 RDI: ffffffffa058b940
[ 210.096906] RBP: ffff88011b2b0578 R08: 00000000852f0ec9 R09: ffffffff81cfcf9b
[ 210.096909] R10: 00000000d21bdad7 R11: 0000000000000001 R12: ffff8800967b0488
[ 210.096913] R13: ffff880107e17168 R14: 0000000000000068 R15: ffff8800949c0008
[ 210.096920] ? __sk_destruct+0x2c6/0x2d4
[ 210.096959] hci_event_packet+0xff5/0x7de2 [bluetooth]
[ 210.096969] ? __local_bh_enable_ip+0x43/0x5b
[ 210.097004] ? l2cap_sock_recv_cb+0x158/0x166 [bluetooth]
[ 210.097039] ? hci_le_meta_evt+0x2bb3/0x2bb3 [bluetooth]
[ 210.097075] ? l2cap_ertm_init+0x94e/0x94e [bluetooth]
[ 210.097093] ? xhci_urb_enqueue+0xbd8/0xcf5 [xhci_hcd]
[ 210.097102] ? __accumulate_pelt_segments+0x24/0x33
[ 210.097109] ? __accumulate_pelt_segments+0x24/0x33
[ 210.097115] ? __update_load_avg_se.isra.2+0x217/0x3a4
[ 210.097122] ? set_next_entity+0x7c3/0x12cd
[ 210.097128] ? pick_next_entity+0x25e/0x26c
[ 210.097135] ? pick_next_task_fair+0x2ca/0xc1a
[ 210.097141] ? switch_mm_irqs_off+0x346/0xb4f
[ 210.097147] ? __switch_to+0x769/0xbc4
[ 210.097153] ? compat_start_thread+0x66/0x66
[ 210.097188] ? hci_conn_check_link_mode+0x1cd/0x1cd [bluetooth]
[ 210.097195] ? finish_task_switch+0x392/0x431
[ 210.097228] ? hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097260] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097269] process_one_work+0x579/0x9e9
[ 210.097277] worker_thread+0x68f/0x804
[ 210.097285] kthread+0x31c/0x32b
[ 210.097292] ? rescuer_thread+0x70c/0x70c
[ 210.097299] ? kthread_create_on_node+0xa3/0xa3
[ 210.097306] ret_from_fork+0x35/0x40[ 210.097314] Allocated by task 2040:
[ 210.097323] kasan_kmalloc.part.1+0x51/0xc7
[ 210.097328] __kmalloc+0x17f/0x1b6
[ 210.097335] sk_prot_alloc+0xf2/0x1a3
[ 210.097340] sk_alloc+0x22/0x297
[ 210.097375] sco_sock_alloc.constprop.7+0x23/0x202 [bluetooth]
[ 210.097410] sco_connect_cfm+0x2d0/0x566 [bluetooth]
[ 210.097443] hci_conn_request_evt.isra.53+0x6d3/0x762 [bluetooth]
[ 210.097476] hci_event_packet+0x85e/0x7de2 [bluetooth]
[ 210.097507] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097512] process_one_work+0x579/0x9e9
[ 210.097517] worker_thread+0x68f/0x804
[ 210.097523] kthread+0x31c/0x32b
[ 210.097529] ret_from_fork+0x35/0x40[ 210.097533] Freed by task 2040:
[ 210.097539] kasan_slab_free+0xb3/0x15e
[ 210.097544] kfree+0x103/0x1a9
[ 210.097549] __sk_destruct+0x2c6/0x2d4
[ 210.097584] sco_conn_del.isra.1+0xba/0x10e [bluetooth]
[ 210.097617] hci_event_packet+0xff5/0x7de2 [bluetooth]
[ 210.097648] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097653] process_one_work+0x579/0x9e9
[ 210.097658] worker_thread+0x68f/0x804
[ 210.097663] kthread+0x31c/0x32b
[ 210.097670] ret_from_fork+0x35/0x40[ 210.097676] The buggy address belongs to the object at ffff880107e170e8
which belongs to the cache kmalloc-1024 of size 1024
[ 210.097681] The buggy address is located 120 bytes inside of
1024-byte region [ffff880107e170e8, ffff880107e174e8)
[ 210.097683] The buggy address belongs to the page:
[ 210.097689] page:ffffea00041f8400 count:1 mapcount:0 mapping: (null) index:0xffff880107e15b68 compound_mapcount: 0
[ 210.110194] flags: 0x8000000000008100(slab|head)
[ 210.115441] raw: 8000000000008100 0000000000000000 ffff880107e15b68 0000000100170016
[ 210.115448] raw: ffffea0004a47620 ffffea0004b48e20 ffff88013b80ed40 0000000000000000
[ 210.115451] page dumped because: kasan: bad access detected[ 210.115454] Memory state around the buggy address:
[ 210.115460] ffff880107e17000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 210.115465] ffff880107e17080: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
[ 210.115469] >ffff880107e17100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115472] ^
[ 210.115477] ffff880107e17180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115481] ffff880107e17200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115483] ==================================================================And finally when BT_DBG() and ftrace was enabled it showed:
-14979 [001] .... 186.104191: sco_sock_kill -14979 [001] .... 186.104191: sco_sock_kill -14979 [001] .... 186.104192: sco_sock_kill: sk ef0497a0 state 9
-14979 [001] .... 186.104193: bt_sock_unlink
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
29 Jun, 2017
1 commit
-
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the Bluetooth sockets. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or one
byte long) result in operating on uninitialized memory while referencing
sa_family.Signed-off-by: Mateusz Jurczyk
Signed-off-by: Marcel Holtmann
10 Mar, 2017
1 commit
-
Lockdep issues a circular dependency warning when AFS issues an operation
through AF_RXRPC from a context in which the VFS/VM holds the mmap_sem.The theory lockdep comes up with is as follows:
(1) If the pagefault handler decides it needs to read pages from AFS, it
calls AFS with mmap_sem held and AFS begins an AF_RXRPC call, but
creating a call requires the socket lock:mmap_sem must be taken before sk_lock-AF_RXRPC
(2) afs_open_socket() opens an AF_RXRPC socket and binds it. rxrpc_bind()
binds the underlying UDP socket whilst holding its socket lock.
inet_bind() takes its own socket lock:sk_lock-AF_RXRPC must be taken before sk_lock-AF_INET
(3) Reading from a TCP socket into a userspace buffer might cause a fault
and thus cause the kernel to take the mmap_sem, but the TCP socket is
locked whilst doing this:sk_lock-AF_INET must be taken before mmap_sem
However, lockdep's theory is wrong in this instance because it deals only
with lock classes and not individual locks. The AF_INET lock in (2) isn't
really equivalent to the AF_INET lock in (3) as the former deals with a
socket entirely internal to the kernel that never sees userspace. This is
a limitation in the design of lockdep.Fix the general case by:
(1) Double up all the locking keys used in sockets so that one set are
used if the socket is created by userspace and the other set is used
if the socket is created by the kernel.(2) Store the kern parameter passed to sk_alloc() in a variable in the
sock struct (sk_kern_sock). This informs sock_lock_init(),
sock_init_data() and sk_clone_lock() as to the lock keys to be used.Note that the child created by sk_clone_lock() inherits the parent's
kern setting.(3) Add a 'kern' parameter to ->accept() that is analogous to the one
passed in to ->create() that distinguishes whether kernel_accept() or
sys_accept4() was the caller and can be passed to sk_alloc().Note that a lot of accept functions merely dequeue an already
allocated socket. I haven't touched these as the new socket already
exists before we get the parameter.Note also that there are a couple of places where I've made the accepted
socket unconditionally kernel-based:irda_accept()
rds_rcp_accept_one()
tcp_accept_from_sock()because they follow a sock_create_kern() and accept off of that.
Whilst creating this, I noticed that lustre and ocfs don't create sockets
through sock_create_kern() and thus they aren't marked as for-kernel,
though they appear to be internal. I wonder if these should do that so
that they use the new set of lock keys.Signed-off-by: David Howells
Signed-off-by: David S. Miller
02 Mar, 2017
1 commit
-
…hed.h> into <linux/sched/signal.h>
Fix up affected files that include this signal functionality via sched.h.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
23 Nov, 2016
1 commit
-
The hci_get_route() API is used to look up local HCI devices, however
so far it has been incapable of dealing with anything else than the
public address of HCI devices. This completely breaks with LE-only HCI
devices that do not come with a public address, but use a static
random address instead.This patch exteds the hci_get_route() API with a src_type parameter
that's used for comparing with the right address of each HCI device.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
16 Dec, 2015
1 commit
-
Signed-off-by: David S. Miller
27 Oct, 2015
1 commit
-
Fix a crash that may happen when a connection is closed before it was fully
established. Mapping conn->hcon was released by shutdown function, but it
is still referenced in (not yet finished) connection established handling
function.[ 4635.254073] BUG: unable to handle kernel NULL pointer dereference at 00000013
[ 4635.262058] IP: [] memcmp+0xe/0x25
[ 4635.266835] *pdpt = 0000000024190001 *pde = 0000000000000000
[ 4635.273261] Oops: 0000 [#1] PREEMPT SMP
[ 4635.277652] Modules linked in: evdev ecb vfat fat libcomposite usb2380 isofs zlib_inflate rfcomm(O) udc_core bnep(O) btusb(O) btbcm(O) btintel(O) bluetooth(O) cdc_acm arc4 uinput hid_mule
[ 4635.321761] Pid: 363, comm: kworker/u:2H Tainted: G O 3.8.0-119.1-plk-adaptation-byt-ivi-brd #1
[ 4635.332642] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
[ 4635.338767] EIP is at memcmp+0xe/0x25
[ 4635.342852] EAX: e4720678 EBX: 00000000 ECX: 00000006 EDX: 00000013
[ 4635.349849] ESI: 00000000 EDI: fb85366c EBP: e40c7dc0 ESP: e40c7db4
[ 4635.356846] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 4635.362873] CR0: 8005003b CR2: 00000013 CR3: 24191000 CR4: 001007f0
[ 4635.369869] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 4635.376865] DR6: ffff0ff0 DR7: 00000400
[ 4635.381143] Process kworker/u:2H (pid: 363, ti=e40c6000 task=e40c5510 task.ti=e40c6000)
[ 4635.390080] Stack:
[ 4635.392319] e4720400 00000000 fb85366c e40c7df4 fb842285 e40c7de2 fb853200 00000013
[ 4635.401003] e3f101c4 e4720678 e3f101c0 e403be0a e40c7dfc e416a000 e403be0a fb85366c
[ 4635.409692] e40c7e1c fb820186 020f6c00 e47c49ac e47c4008 00000000 e416a000 e47c402c
[ 4635.418380] Call Trace:
[ 4635.421153] [] sco_connect_cfm+0xff/0x236 [bluetooth]
[ 4635.427893] [] hci_sync_conn_complete_evt.clone.101+0x227/0x268 [bluetooth]
[ 4635.436758] [] hci_event_packet+0x1caa/0x21d3 [bluetooth]
[ 4635.443859] [] ? trace_hardirqs_on+0xb/0xd
[ 4635.449502] [] ? _raw_spin_unlock_irqrestore+0x42/0x59
[ 4635.456340] [] hci_rx_work+0xb9/0x350 [bluetooth]
[ 4635.462663] [] ? process_one_work+0x17b/0x2e6
[ 4635.468596] [] process_one_work+0x1d4/0x2e6
[ 4635.474333] [] ? process_one_work+0x17b/0x2e6
[ 4635.480294] [] ? hci_cmd_work+0xda/0xda [bluetooth]
[ 4635.486810] [] worker_thread+0x171/0x20f
[ 4635.492257] [] ? complete+0x34/0x3e
[ 4635.497219] [] kthread+0x90/0x95
[ 4635.501888] [] ? manage_workers+0x1df/0x1df
[ 4635.507628] [] ret_from_kernel_thread+0x1b/0x28
[ 4635.513755] [] ? __init_kthread_worker+0x42/0x42
[ 4635.519975] Code: 74 0d 3c 79 74 04 3c 59 75 0c c6 02 01 eb 03 c6 02 00 31 c0 eb 05 b8 ea ff ff ff 5d c3 55 89 e5 57 56 53 31 db eb 0e 0f b6 34 18 b6 3c 1a 43 29 fe 75 07 49 85 c9 7f
[ 4635.541264] EIP: [] memcmp+0xe/0x25 SS:ESP 0068:e40c7db4
[ 4635.548166] CR2: 0000000000000013
[ 4635.552177] ---[ end trace e05ce9b8ce6182f6 ]---Signed-off-by: Kuba Pawlak
Signed-off-by: Marcel Holtmann
26 Oct, 2015
4 commits
-
Lets fix this obvious coding style issues in the SCO module and bring it
in line with the rest of the Bluetooth subsystem.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
When SCO connection is requested and disconnected fast, there is a change
that sco_sock_shutdown is going to preempt thread started in sco_connect_cfm.
When this happens struct sock sk may be removed but a pointer to it is still
held in sco_conn_ready, where embedded spinlock is used. If it is used, but
struct sock has been removed, it will crash.Block connection object, which will prevent struct sock from being removed
and give connection process chance to finish.BUG: spinlock bad magic on CPU#0, kworker/u:2H/319
lock: 0xe3e99434, .magic: f3000000, .owner: (���/0, .owner_cpu: -203804160
Pid: 319, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1
Call Trace:
[] ? do_raw_spin_lock+0x19/0xe9
[] ? sco_connect_cfm+0x92/0x236 [bluetooth]
[] ? hci_sync_conn_complete_evt.clone.101+0x18b/0x1cb [bluetooth]
[] ? hci_event_packet+0x1acd/0x21a6 [bluetooth]
[] ? finish_task_switch+0x50/0x89
[] ? __schedule+0x638/0x6b8
[] ? hci_rx_work+0xb9/0x2b8 [bluetooth]
[] ? queue_delayed_work_on+0x21/0x2a
[] ? process_one_work+0x157/0x21b
[] ? hci_cmd_work+0xef/0xef [bluetooth]
[] ? worker_thread+0x16e/0x20a
[] ? manage_workers+0x1cf/0x1cf
[] ? kthread+0x8d/0x92
[] ? ret_from_kernel_thread+0x1b/0x28
[] ? __init_kthread_worker+0x24/0x24
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
*pdpt = 00000000244e1001 *pde = 0000000000000000
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) cdc_acm btintel(O) bluetooth(O) arc4 uinput hid_multitouch usbhid hid iwlmvm(O)e
Pid: 319, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at 0x0
EAX: e3e99400 EBX: e3e99400 ECX: 00000100 EDX: 00000000
ESI: e3e99434 EDI: fb763ce0 EBP: e49b9e44 ESP: e49b9e14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 24444000 CR4: 001007f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process kworker/u:2H (pid: 319, ti=e49b8000 task=e4ab9030 task.ti=e49b8000)
Stack:
fb75355b 00000246 fb763900 22222222 22222222 22222222 e3f94460 e3ca7c0a
e49b9e4c e3f34c00 e3ca7c0a fb763ce0 e49b9e6c fb731dbc 02000246 e4cec85c
e4cec008 00000000 e3f34c00 e4cec000 e3c2ce00 0000002c e49b9ed0 fb734ee7
Call Trace:
[] ? sco_connect_cfm+0x9e/0x236 [bluetooth]
[] ? hci_sync_conn_complete_evt.clone.101+0x18b/0x1cb [bluetooth]
[] ? hci_event_packet+0x1acd/0x21a6 [bluetooth]
[] ? finish_task_switch+0x50/0x89
[] ? __schedule+0x638/0x6b8
[] ? hci_rx_work+0xb9/0x2b8 [bluetooth]
[] ? queue_delayed_work_on+0x21/0x2a
[] ? process_one_work+0x157/0x21b
[] ? hci_cmd_work+0xef/0xef [bluetooth]
[] ? worker_thread+0x16e/0x20a
[] ? manage_workers+0x1cf/0x1cf
[] ? kthread+0x8d/0x92
[] ? ret_from_kernel_thread+0x1b/0x28
[] ? __init_kthread_worker+0x24/0x24
Code: Bad EIP value.
EIP: [] 0x0 SS:ESP 0068:e49b9e14
CR2: 0000000000000000
---[ end trace 942a6577c0abd725 ]---Signed-off-by: Kuba Pawlak
Signed-off-by: Marcel Holtmann -
Thread handling SCO disconnection may get preempted in '__sco_sock_close'
after dropping a reference to hci_conn but before marking this as NULL
in associated struct sco_conn. When execution returs to this thread,
this connection will possibly be released, resulting in kernel crashLock connection before this point.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __sco_sock_close+0x194/0x1ff [bluetooth]
*pdpt = 0000000023da6001 *pde = 0000000000000000
Oops: 0002 [#1] PREEMPT SMP
Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) cdc_acm btintel(O) bluetooth(O) arc4 uinput hid_multitouch usbhid iwlmvm(O) hide
Pid: 984, comm: bluetooth Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1
EIP: 0060:[] EFLAGS: 00010282 CPU: 2
EIP is at __sco_sock_close+0x194/0x1ff [bluetooth]
EAX: 00000000 EBX: e49d7600 ECX: ef1ec3c2 EDX: 000000c3
ESI: e4c12000 EDI: 00000000 EBP: ef1edf5c ESP: ef1edf4c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 80050033 CR2: 00000000 CR3: 23da7000 CR4: 001007f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process bluetooth (pid: 984, ti=ef1ec000 task=e47f2550 task.ti=ef1ec000)
Stack:
e4c120d0 e49d7600 00000000 08421a40 ef1edf70 fb770b7a 00000002 e8a4cc80
08421a40 ef1ec000 c12966b1 00000001 00000000 0000000b 084954c8 c1296b6c
0000001b 00000002 0000001b 00000002 00000000 00000002 b2524880 00000046
Call Trace:
[] ? sco_sock_shutdown+0x56/0x95 [bluetooth]
[] ? sys_shutdown+0x37/0x53
[] ? sys_socketcall+0x12e/0x1be
[] ? sysenter_do_call+0x12/0x26
[] ? ip_vs_control_net_cleanup+0x46/0xb1
Code: e8 90 6b 8c c5 f6 05 72 5d 78 fb 04 74 17 8b 46 08 50 56 68 0a fd 77 fb 68 60 5d 78 fb e8 68 95 9e c5 83 c4 10 8b 83 fc 01 00 00 00 00 00 00 00 eb 32 ba 68 00 00 0b
EIP: [] __sco_sock_close+0x194/0x1ff [bluetooth] SS:ESP 0068:ef1edf4c
CR2: 0000000000000000
---[ end trace 47fa2f55a9544e69 ]---Signed-off-by: Kuba Pawlak
Signed-off-by: Marcel Holtmann -
When disconnecting audio from the phone's side, it may happen, that
a thread handling HCI message 'disconnection complete' will get preempted
in 'sco_conn_del' before calling 'sco_sock_kill', still holding a pointer
to struct sock sk. Interrupting thread started in 'sco_sock_shutdown' will
carry on releasing resources and will eventually release struct sock.
When execution goes back to first thread it will call sco_sock_kill using
now invalid pointer to already destroyed socket.Fix is to grab a reference to the socket a release it after calling
'sco_sock_kill'.[ 166.358213] BUG: unable to handle kernel paging request at 7541203a
[ 166.365228] IP: [] bt_sock_unlink+0x1a/0x38 [bluetooth]
[ 166.372068] *pdpt = 0000000024b19001 *pde = 0000000000000000
[ 166.378483] Oops: 0002 [#1] PREEMPT SMP
[ 166.382871] Modules linked in: evdev ecb rfcomm(O) libcomposite usb2380 udc_core bnep(O) btusb(O) btbcm(O) btintel(O) cdc_acm bluetooth(O) arc4 uinput hid_multitouch iwlmvm(O) usbhid hide
[ 166.424233] Pid: 338, comm: kworker/u:2H Tainted: G O 3.8.0-115.1-plk-adaptation-byt-ivi-brd #1
[ 166.435112] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
[ 166.441259] EIP is at bt_sock_unlink+0x1a/0x38 [bluetooth]
[ 166.447382] EAX: 632e6563 EBX: e4bfc600 ECX: e466d4d3 EDX: 7541203a
[ 166.454369] ESI: fb7278ac EDI: e4d52000 EBP: e4669e20 ESP: e4669e0c
[ 166.461366] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 166.467391] CR0: 8005003b CR2: 7541203a CR3: 24aba000 CR4: 001007f0
[ 166.474387] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 166.481375] DR6: ffff0ff0 DR7: 00000400
[ 166.485654] Process kworker/u:2H (pid: 338, ti=e4668000 task=e466e030 task.ti=e4668000)
[ 166.494591] Stack:
[ 166.496830] e4bfc600 e4bfc600 fb715c28 e4717ee0 e4d52000 e4669e3c fb715cf3 e4bfc634
[ 166.505518] 00000068 e4d52000 e4c32000 fb7277c0 e4669e6c fb6f2019 0000004a 00000216
[ 166.514205] e4660101 e4c32008 02000001 00000013 e4d52000 e4c32000 e3dc9240 00000005
[ 166.522891] Call Trace:
[ 166.525654] [] ? sco_sock_kill+0x73/0x9a [bluetooth]
[ 166.532295] [] ? sco_conn_del+0xa4/0xbf [bluetooth]
[ 166.538836] [] ? hci_disconn_complete_evt.clone.55+0x1bd/0x205 [bluetooth]
[ 166.547609] [] ? hci_event_packet+0x297/0x223c [bluetooth]
[ 166.554805] [] ? dequeue_task+0xaf/0xb7
[ 166.560154] [] ? finish_task_switch+0x50/0x89
[ 166.566086] [] ? __schedule+0x638/0x6b8
[ 166.571460] [] ? hci_rx_work+0xb9/0x2b8 [bluetooth]
[ 166.577975] [] ? process_one_work+0x157/0x21b
[ 166.583933] [] ? hci_cmd_work+0xef/0xef [bluetooth]
[ 166.590448] [] ? worker_thread+0x16e/0x20a
[ 166.596088] [] ? manage_workers+0x1cf/0x1cf
[ 166.601826] [] ? kthread+0x8d/0x92
[ 166.606691] [] ? ret_from_kernel_thread+0x1b/0x28
[ 166.613010] [] ? __init_kthread_worker+0x24/0x24
[ 166.619230] Code: 85 63 ff ff ff 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 56 8d 70 04 53 89 f0 89 d3 e8 7e 17 c6 c5 8b 53 28 85 d2 74 1a 8b 43 24 85 c0 02 74 03 89 50 04 c7 43 28 00 00 00
[ 166.640501] EIP: [] bt_sock_unlink+0x1a/0x38 [bluetooth] SS:ESP 0068:e4669e0c
[ 166.649474] CR2: 000000007541203a
[ 166.653420] ---[ end trace 0181ff2c9e42d51e ]---
[ 166.658609] note: kworker/u:2H[338] exited with preempt_count 1Signed-off-by: Kuba Pawlak
Signed-off-by: Marcel Holtmann
29 Aug, 2015
1 commit
-
This makes the function sco_conn_del have a return type of void now
due to this function always running successfully and thus never
needing to signal its caller when a non recoverable internal failure
occurs by returning a error code to its respective caller.Signed-off-by: Nicholas Krause
Signed-off-by: Marcel Holtmann
09 Jun, 2015
1 commit
-
The return value of l2cap_recv_acldata() and sco_recv_scodata()
are not used, then change it to return voidSigned-off-by: Arron Wang
Signed-off-by: Marcel Holtmann
11 May, 2015
1 commit
-
In preparation for changing how struct net is refcounted
on kernel sockets pass the knowledge that we are creating
a kernel socket from sock_create_kern through to sk_alloc.Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
08 Mar, 2015
1 commit
-
While compiling the following warning occurs:
WARNING: net/built-in.o(.init.text+0x602c): Section mismatch in
reference from the function bt_init() to the function
.exit.text:sco_exit()
The function __init bt_init() references
a function __exit sco_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __exit annotation of
sco_exit() so it may be used outside an exit section.Since commit 6d785aa345f525e1fdf098b7c590168f0b00f3f1 ("Bluetooth:
Convert mgmt to use HCI chan registration API") the function "sco_exit"
is used inside of function "bt_init". The suggested solution by remove
the __exit annotation solved this issue.Signed-off-by: Alexander Aring
Signed-off-by: Johan Hedberg
03 Mar, 2015
2 commits
-
…etooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2015-03-02Here's the first bluetooth-next pull request targeting the 4.1 kernel:
- ieee802154/6lowpan cleanups
- SCO routing to host interface support for the btmrvl driver
- AMP code cleanups
- Fixes to AMP HCI init sequence
- Refactoring of the HCI callback mechanism
- Added shutdown routine for Intel controllers in the btusb driver
- New config option to enable/disable Bluetooth debugfs information
- Fix for early data reception on L2CAP fixed channelsPlease let me know if there are any issues pulling. Thanks.
====================Signed-off-by: David S. Miller <davem@davemloft.net>
-
After TIPC doesn't depend on iocb argument in its internal
implementations of sendmsg() and recvmsg() hooks defined in proto
structure, no any user is using iocb argument in them at all now.
Then we can drop the redundant iocb argument completely from kinds of
implementations of both sendmsg() and recvmsg() in the entire
networking stack.Cc: Christoph Hellwig
Suggested-by: Al Viro
Signed-off-by: Ying Xue
Signed-off-by: David S. Miller
19 Feb, 2015
2 commits
-
This patch moves all the disconn_cfm callbacks to be based on the hci_cb
list. This means making l2cap_disconn_cfm private to l2cap_core.c and
sco_conn_cb private to sco.c respectively. Since the hci_conn type
filtering isn't done any more on the wrapper level the callbacks
themselves need to check that they were passed a relevant type of
connection.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann -
This patch moves all the connect_cfm callbacks to be based on the hci_cb
list. This means making l2cap_connect_cfm private to l2cap_core.c and
sco_connect_cb private to sco.c respectively. Since the hci_conn type
filtering isn't done any more on the wrapper level the callbacks
themselves need to check that they were passed a relevant type of
connection.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
24 Jan, 2015
1 commit
-
l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire
sleeping locks. Since both wait loops and sleeping locks use
task_struct.state to sleep and wake, the nested sleeping locks
destroy the wait loop state.Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the
wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function
to be specified; in this case, the predefined scheduler function,
woken_wake_function(). This wait construct ensures wakeups will
not be missed without requiring the wait loop to set the
task state before condition evaluation. How this works:CPU 0 | CPU 1
|
| is set?
| no
set |
|
wake_up_interruptible |
woken_wake_function |
set WQ_FLAG_WOKEN |
try_to_wake_up |
| wait_woken
| set TASK_INTERRUPTIBLE
| WQ_FLAG_WOKEN? yes
| set TASK_RUNNING
|
| - loop -
|
| is set?
| yes - exit wait loopFixes "do not call blocking ops when !TASK_RUNNING" warnings
in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept().Signed-off-by: Peter Hurley
Signed-off-by: Johan Hedberg
12 Jan, 2015
1 commit
-
This adds an extra check for ensuring that the size of sockaddr_sco
does not grow larger than sockaddr.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
24 Nov, 2014
1 commit
-
Signed-off-by: Al Viro
17 Jul, 2014
1 commit
-
If the current process is exiting, lingering on socket close will make
it unkillable, so we should avoid it.Reproducer:
#include
#include#define BTPROTO_L2CAP 0
#define BTPROTO_SCO 2
#define BTPROTO_RFCOMM 3int main()
{
int fd;
struct linger ling;fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
//or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
//or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);ling.l_onoff = 1;
ling.l_linger = 1000000000;
setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));return 0;
}Signed-off-by: Vladimir Davydov
Signed-off-by: Marcel Holtmann
Cc: stable@vger.kernel.org
14 Jul, 2014
3 commits
-
The sco_chan_get helper function is only used in two places and really
only protects conn->sk with a lock. So instead of hiding that fact,
just put the actual code in place where it is used.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
The forward declaration of sco_chan_del is not needed and thus just
remove it. Move sco_chan_del into the proper location.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
The forward declaration of __sco_chan_add is not needed and thus just
remove it. Move __sco_chan_add into the proper location.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
11 Jul, 2014
3 commits
-
There is no external user of the SCO timeout constants and thus
move them into net/bluetooth/sco.c where they are actuallu used.In addition just remove SCO_CONN_IDLE_TIMEOUT since it is unused.
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
There exists no external user of struct sco_conn and thus move
it into the one place that is actually using it.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
There exists no external user of struct sco_pinfo and sco_pi and
thus move it into the one place that is actually using it.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
12 Apr, 2014
1 commit
-
Several spots in the kernel perform a sequence like:
skb_queue_tail(&sk->s_receive_queue, skb);
sk->sk_data_ready(sk, skb->len);But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up. So this skb->len access is potentially
to freed up memory.Furthermore, the skb->len can be modified by the consumer so it is
possible that the value isn't accurate.And finally, no actual implementation of this callback actually uses
the length argument. And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.Signed-off-by: David S. Miller
13 Mar, 2014
1 commit
-
The use of __constant_ has been unnecessary for quite awhile now.
Make these uses consistent with the rest of the kernel.
Signed-off-by: Joe Perches
Signed-off-by: Marcel Holtmann
21 Nov, 2013
1 commit
-
This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size
Suggested-by: Eric Dumazet
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
18 Oct, 2013
1 commit
-
Make sure to use IS_ERR_OR_NULL for checking the existing of the root
debugfs dentry bt_debugfs.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
14 Oct, 2013
2 commits
-
The address information of SCO sockets should be stored in its own
socket structure. Trying to generalize them is not helpful since
different transports have different address types.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
Instead of storing a pointer to the addresses for the HCI device
and HCI connection, use them directly. With the recent changes
to address tracking of HCI connections, this becomes simple.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
21 Aug, 2013
5 commits
-
Older Bluetooth devices may not support Setup Synchronous Connection or
SCO transparent data. This is indicated by the corresponding LMP feature
bits. It is not possible to know if the adapter support these features
before setting BT_VOICE option since the socket is not bound to an
adapter. An adapter can also be added after the socket is created. The
socket can be bound to an address before adapter is plugged in.Thus, on a such adapters, if user request BT_VOICE_TRANSPARENT, outgoing
connections fail on connect() and returns -EOPNOTSUPP. Incoming
connections do not fail. However, they should only be allowed depending
on what was specified in Write_Voice_Settings command.EOPNOTSUPP is choosen because connect() system call is failing after
selecting route but before any connection attempt.Signed-off-by: Frédéric Dalleau
Signed-off-by: Johan Hedberg
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan -
In order to establish a transparent SCO connection, the correct settings
must be specified in the Setup Synchronous Connection request. For that,
a setting field is added to ACL connection data to set up the desired
parameters. The patch also removes usage of hdev->voice_setting in CVSD
connection and makes use of T2 parameters for transparent data.Signed-off-by: Frédéric Dalleau
Signed-off-by: Johan Hedberg
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan -
When an incoming eSCO connection is requested, check the selected voice
setting and reply appropriately. Voice setting should have been
negotiated previously. For example, in case of HFP, the codec is
negotiated using AT commands on the RFCOMM channel. This patch only
changes replies for socket with deferred setup enabled.Signed-off-by: Frédéric Dalleau
Signed-off-by: Johan Hedberg
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo Padovan -
This patch extends the current Bluetooth socket options with BT_VOICE.
This is intended to choose voice data type at runtime. It only applies
to SCO sockets. Incoming connections shall be setup during deferred
setup. Outgoing connections shall be setup before connect(). The desired
setting is stored in the SCO socket info. This patch declares needed
members, modifies getsockopt() and setsockopt().Signed-off-by: Frédéric Dalleau
Acked-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
Signed-off-by: Gustavo Padovan -
From Bluetooth Core v4.0 specification, 7.1.8 Accept Connection Request
Command "When accepting synchronous connection request, the Role
parameter is not used and will be ignored by the BR/EDR Controller."Signed-off-by: Frédéric Dalleau
Acked-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
Signed-off-by: Gustavo Padovan
