| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Fix double free of skb in coredump
hci_devcd_append() would free the skb on error so the caller don't
have to free it again otherwise it would cause the double free of skb.
Reported-by : Dan Carpenter <dan.carpenter@linaro.org> |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
If we received HCI_EV_IO_CAPA_REQUEST while
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
does support SSP since otherwise this event shouldn't be generated. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:
Cleanup Thread | Worker Thread
sco_sock_release |
sco_sock_close |
__sco_sock_close |
sco_sock_set_timer |
schedule_delayed_work |
sco_sock_kill | (wait a time)
sock_put(sk) //FREE | sco_sock_timeout
| sock_hold(sk) //USE
The KASAN report triggered by POC is shown below:
[ 95.890016] ==================================================================
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[ 95.890755] Workqueue: events sco_sock_timeout
[ 95.890755] Call Trace:
[ 95.890755] <TASK>
[ 95.890755] dump_stack_lvl+0x45/0x110
[ 95.890755] print_address_description+0x78/0x390
[ 95.890755] print_report+0x11b/0x250
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
[ 95.890755] kasan_report+0x139/0x170
[ 95.890755] ? update_load_avg+0xe5/0x9f0
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
[ 95.890755] kasan_check_range+0x2c3/0x2e0
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
[ 95.890755] process_one_work+0x561/0xc50
[ 95.890755] worker_thread+0xab2/0x13c0
[ 95.890755] ? pr_cont_work+0x490/0x490
[ 95.890755] kthread+0x279/0x300
[ 95.890755] ? pr_cont_work+0x490/0x490
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
[ 95.890755] ret_from_fork+0x34/0x60
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
[ 95.890755] ret_from_fork_asm+0x11/0x20
[ 95.890755] </TASK>
[ 95.890755]
[ 95.890755] Allocated by task 506:
[ 95.890755] kasan_save_track+0x3f/0x70
[ 95.890755] __kasan_kmalloc+0x86/0x90
[ 95.890755] __kmalloc+0x17f/0x360
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
[ 95.890755] sk_alloc+0x31/0x4e0
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
[ 95.890755] sco_sock_create+0xad/0x320
[ 95.890755] bt_sock_create+0x145/0x320
[ 95.890755] __sock_create+0x2e1/0x650
[ 95.890755] __sys_socket+0xd0/0x280
[ 95.890755] __x64_sys_socket+0x75/0x80
[ 95.890755] do_syscall_64+0xc4/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
[ 95.890755]
[ 95.890755] Freed by task 506:
[ 95.890755] kasan_save_track+0x3f/0x70
[ 95.890755] kasan_save_free_info+0x40/0x50
[ 95.890755] poison_slab_object+0x118/0x180
[ 95.890755] __kasan_slab_free+0x12/0x30
[ 95.890755] kfree+0xb2/0x240
[ 95.890755] __sk_destruct+0x317/0x410
[ 95.890755] sco_sock_release+0x232/0x280
[ 95.890755] sock_close+0xb2/0x210
[ 95.890755] __fput+0x37f/0x770
[ 95.890755] task_work_run+0x1ae/0x210
[ 95.890755] get_signal+0xe17/0xf70
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
[ 95.890755] do_syscall_64+0xd1/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
[ 95.890755]
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
[ 95.890755] The buggy address is located 128 bytes inside of
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
[ 95.890755]
[ 95.890755] The buggy address belongs to the physical page:
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 95.890755] ano
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: fix out of bounds memory access
The problem is detected by KASAN.
btrtl driver uses private hci data to store 'struct btrealtek_data'.
If btrtl driver is used with btusb, then memory for private hci data
is allocated in btusb. But no private data is allocated after hci_dev,
when btrtl is used with hci_h5.
This commit adds memory allocation for hci_h5 case.
==================================================================
BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl]
Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76
Hardware name: Pine64 PinePhone (1.2) (DT)
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
dump_backtrace+0x9c/0x128
show_stack+0x20/0x38
dump_stack_lvl+0x48/0x60
print_report+0xf8/0x5d8
kasan_report+0x90/0xd0
__asan_store8+0x9c/0xc0
[btrtl]
h5_btrtl_setup+0xd0/0x2f8 [hci_uart]
h5_setup+0x50/0x80 [hci_uart]
hci_uart_setup+0xd4/0x260 [hci_uart]
hci_dev_open_sync+0x1cc/0xf68 [bluetooth]
hci_dev_do_open+0x34/0x90 [bluetooth]
hci_power_on+0xc4/0x3c8 [bluetooth]
process_one_work+0x328/0x6f0
worker_thread+0x410/0x778
kthread+0x168/0x178
ret_from_fork+0x10/0x20
Allocated by task 53:
kasan_save_stack+0x3c/0x68
kasan_save_track+0x20/0x40
kasan_save_alloc_info+0x68/0x78
__kasan_kmalloc+0xd4/0xd8
__kmalloc+0x1b4/0x3b0
hci_alloc_dev_priv+0x28/0xa58 [bluetooth]
hci_uart_register_device+0x118/0x4f8 [hci_uart]
h5_serdev_probe+0xf4/0x178 [hci_uart]
serdev_drv_probe+0x54/0xa0
really_probe+0x254/0x588
__driver_probe_device+0xc4/0x210
driver_probe_device+0x64/0x160
__driver_attach_async_helper+0x88/0x158
async_run_entry_fn+0xd0/0x388
process_one_work+0x328/0x6f0
worker_thread+0x410/0x778
kthread+0x168/0x178
ret_from_fork+0x10/0x20
Last potentially related work creation:
kasan_save_stack+0x3c/0x68
__kasan_record_aux_stack+0xb0/0x150
kasan_record_aux_stack_noalloc+0x14/0x20
__queue_work+0x33c/0x960
queue_work_on+0x98/0xc0
hci_recv_frame+0xc8/0x1e8 [bluetooth]
h5_complete_rx_pkt+0x2c8/0x800 [hci_uart]
h5_rx_payload+0x98/0xb8 [hci_uart]
h5_recv+0x158/0x3d8 [hci_uart]
hci_uart_receive_buf+0xa0/0xe8 [hci_uart]
ttyport_receive_buf+0xac/0x178
flush_to_ldisc+0x130/0x2c8
process_one_work+0x328/0x6f0
worker_thread+0x410/0x778
kthread+0x168/0x178
ret_from_fork+0x10/0x20
Second to last potentially related work creation:
kasan_save_stack+0x3c/0x68
__kasan_record_aux_stack+0xb0/0x150
kasan_record_aux_stack_noalloc+0x14/0x20
__queue_work+0x788/0x960
queue_work_on+0x98/0xc0
__hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth]
__hci_cmd_sync+0x24/0x38 [bluetooth]
btrtl_initialize+0x760/0x958 [btrtl]
h5_btrtl_setup+0xd0/0x2f8 [hci_uart]
h5_setup+0x50/0x80 [hci_uart]
hci_uart_setup+0xd4/0x260 [hci_uart]
hci_dev_open_sync+0x1cc/0xf68 [bluetooth]
hci_dev_do_open+0x34/0x90 [bluetooth]
hci_power_on+0xc4/0x3c8 [bluetooth]
process_one_work+0x328/0x6f0
worker_thread+0x410/0x778
kthread+0x168/0x178
ret_from_fork+0x10/0x20
================================================================== |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+0x1d8/0x33f
worker_thread+0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/0x54
? kthread_blkcg+0x31/0x31
ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()
KASAN reports that there's a use-after-free in
hci_remove_adv_monitor(). Trawling through the disassembly, you can
see that the complaint is from the access in bt_dev_dbg() under the
HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
msft_remove_monitor() can end up freeing the monitor
structure. Specifically:
hci_remove_adv_monitor() ->
msft_remove_monitor() ->
msft_remove_monitor_sync() ->
msft_le_cancel_monitor_advertisement_cb() ->
hci_free_adv_monitor()
Let's fix the problem by just stashing the relevant data when it's
still valid. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp}
Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free
caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to
prevent referencing a channel that is about to be destroyed. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without
hci_conn_get, so disconn_cfm must be called so they can clean up their
conn, otherwise use-after-free occurs.
ISO:
==========================================================
iso_sock_connect:880: sk 00000000eabd6557
iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da
...
iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073
hci_dev_put:1487: hci0 orig refcnt 17
__iso_chan_add:214: conn 00000000b6251073
iso_sock_clear_timer:117: sock 00000000eabd6557 state 3
...
hci_rx_work:4085: hci0 Event packet
hci_event_packet:7601: hci0: event 0x0f
hci_cmd_status_evt:4346: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3107: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560
hci_conn_unlink:1102: hci0: hcon 000000001696f1fd
hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2
hci_chan_list_flush:2780: hcon 000000001696f1fd
hci_dev_put:1487: hci0 orig refcnt 21
hci_dev_put:1487: hci0 orig refcnt 20
hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c
... <no iso_* activity on sk/conn> ...
iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557
BUG: kernel NULL pointer dereference, address: 0000000000000668
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth
==========================================================
L2CAP:
==================================================================
hci_cmd_status_evt:4359: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3085: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585
hci_conn_unlink:1102: hci0: hcon ffff88800c999000
hci_chan_list_flush:2780: hcon ffff88800c999000
hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280
...
BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]
Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x90
print_report+0xcf/0x670
? __virt_addr_valid+0xf8/0x180
? hci_send_acl+0x2d/0x540 [bluetooth]
kasan_report+0xa8/0xe0
? hci_send_acl+0x2d/0x540 [bluetooth]
hci_send_acl+0x2d/0x540 [bluetooth]
? __pfx___lock_acquire+0x10/0x10
l2cap_chan_send+0x1fd/0x1300 [bluetooth]
? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]
? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]
? lock_release+0x1d5/0x3c0
? mark_held_locks+0x1a/0x90
l2cap_sock_sendmsg+0x100/0x170 [bluetooth]
sock_write_iter+0x275/0x280
? __pfx_sock_write_iter+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
do_iter_readv_writev+0x176/0x220
? __pfx_do_iter_readv_writev+0x10/0x10
? find_held_lock+0x83/0xa0
? selinux_file_permission+0x13e/0x210
do_iter_write+0xda/0x340
vfs_writev+0x1b4/0x400
? __pfx_vfs_writev+0x10/0x10
? __seccomp_filter+0x112/0x750
? populate_seccomp_data+0x182/0x220
? __fget_light+0xdf/0x100
? do_writev+0x19d/0x210
do_writev+0x19d/0x210
? __pfx_do_writev+0x10/0x10
? mark_held_locks+0x1a/0x90
do_syscall_64+0x60/0x90
? lockdep_hardirqs_on_prepare+0x149/0x210
? do_syscall_64+0x6c/0x90
? lockdep_hardirqs_on_prepare+0x149/0x210
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7ff45cb23e64
Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX:
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier
may still be accessing it, it can cause the program to crash.
Here's the call trace:
<4>[102152.653246] Call Trace:
<4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]
<4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]
<4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]
<4>[102152.653268] notifier_call_chain+0x43/0x6b
<4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69
<4>[102152.653273] __pm_notifier_call_chain+0x22/0x39
<4>[102152.653276] pm_suspend+0x287/0x57c
<4>[102152.653278] state_store+0xae/0xe5
<4>[102152.653281] kernfs_fop_write+0x109/0x173
<4>[102152.653284] __vfs_write+0x16f/0x1a2
<4>[102152.653287] ? selinux_file_permission+0xca/0x16f
<4>[102152.653289] ? security_file_permission+0x36/0x109
<4>[102152.653291] vfs_write+0x114/0x21d
<4>[102152.653293] __x64_sys_write+0x7b/0xdb
<4>[102152.653296] do_syscall_64+0x59/0x194
<4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while
processing it in hci_suspend_notifier to avoid potential crash
caused by the race condition. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early
Not calling hci_(dis)connect_cfm before deleting conn referred to by a
socket generally results to use-after-free.
When cleaning up SCO connections when the parent ACL is deleted too
early, use hci_conn_failed to do the connection cleanup properly.
We also need to clean up ISO connections in a similar situation when
connecting has started but LE Create CIS is not yet sent, so do it too
here. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free
Fix potential use-after-free in l2cap_le_command_rej. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp
conn->chan_lock isn't acquired before l2cap_get_chan_by_scid,
if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance'
is triggered. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HCI: Fix global-out-of-bounds
To loop a variable-length array, hci_init_stage_sync(stage) considers
that stage[i] is valid as long as stage[i-1].func is valid.
Thus, the last element of stage[].func should be intentionally invalid
as hci_init0[], le_init2[], and others did.
However, amp_init1[] and amp_init2[] have no invalid element, letting
hci_init_stage_sync() keep accessing amp_init1[] over its valid range.
This patch fixes this by adding {} in the last of amp_init1[] and
amp_init2[].
==================================================================
BUG: KASAN: global-out-of-bounds in hci_dev_open_sync (
/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
/v6.2-bzimage/net/bluetooth/hci_sync.c:3343
/v6.2-bzimage/net/bluetooth/hci_sync.c:4418
/v6.2-bzimage/net/bluetooth/hci_sync.c:4609
/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032
CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04
Workqueue: hci1 hci_power_on
Call Trace:
<TASK>
dump_stack_lvl (/v6.2-bzimage/lib/dump_stack.c:107 (discriminator 1))
print_report (/v6.2-bzimage/mm/kasan/report.c:307
/v6.2-bzimage/mm/kasan/report.c:417)
? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
/v6.2-bzimage/net/bluetooth/hci_sync.c:3343
/v6.2-bzimage/net/bluetooth/hci_sync.c:4418
/v6.2-bzimage/net/bluetooth/hci_sync.c:4609
/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
kasan_report (/v6.2-bzimage/mm/kasan/report.c:184
/v6.2-bzimage/mm/kasan/report.c:519)
? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
/v6.2-bzimage/net/bluetooth/hci_sync.c:3343
/v6.2-bzimage/net/bluetooth/hci_sync.c:4418
/v6.2-bzimage/net/bluetooth/hci_sync.c:4609
/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
/v6.2-bzimage/net/bluetooth/hci_sync.c:3343
/v6.2-bzimage/net/bluetooth/hci_sync.c:4418
/v6.2-bzimage/net/bluetooth/hci_sync.c:4609
/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
? __pfx_hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:4635)
? mutex_lock (/v6.2-bzimage/./arch/x86/include/asm/atomic64_64.h:190
/v6.2-bzimage/./include/linux/atomic/atomic-long.h:443
/v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781
/v6.2-bzimage/kernel/locking/mutex.c:171
/v6.2-bzimage/kernel/locking/mutex.c:285)
? __pfx_mutex_lock (/v6.2-bzimage/kernel/locking/mutex.c:282)
hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:485
/v6.2-bzimage/net/bluetooth/hci_core.c:984)
? __pfx_hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:969)
? read_word_at_a_time (/v6.2-bzimage/./include/asm-generic/rwonce.h:85)
? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62
/v6.2-bzimage/lib/string.c:161)
process_one_work (/v6.2-bzimage/kernel/workqueue.c:2294)
worker_thread (/v6.2-bzimage/./include/linux/list.h:292
/v6.2-bzimage/kernel/workqueue.c:2437)
? __pfx_worker_thread (/v6.2-bzimage/kernel/workqueue.c:2379)
kthread (/v6.2-bzimage/kernel/kthread.c:376)
? __pfx_kthread (/v6.2-bzimage/kernel/kthread.c:331)
ret_from_fork (/v6.2-bzimage/arch/x86/entry/entry_64.S:314)
</TASK>
The buggy address belongs to the variable:
amp_init1+0x30/0x60
The buggy address belongs to the physical page:
page:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix race condition in hci_cmd_sync_clear
There is a potential race condition in hci_cmd_sync_work and
hci_cmd_sync_clear, and could lead to use-after-free. For instance,
hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync
The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and
causing kernel panic when it is used in 'hci_cmd_sync_work'.
Here's the call trace:
dump_stack_lvl+0x49/0x63
print_report.cold+0x5e/0x5d3
? hci_cmd_sync_work+0x282/0x320
kasan_report+0xaa/0x120
? hci_cmd_sync_work+0x282/0x320
__asan_report_load8_noabort+0x14/0x20
hci_cmd_sync_work+0x282/0x320
process_one_work+0x77b/0x11c0
? _raw_spin_lock_irq+0x8e/0xf0
worker_thread+0x544/0x1180
? poll_idle+0x1e0/0x1e0
kthread+0x285/0x320
? process_one_work+0x11c0/0x11c0
? kthread_complete_and_exit+0x30/0x30
ret_from_fork+0x22/0x30
</TASK>
Allocated by task 266:
kasan_save_stack+0x26/0x50
__kasan_kmalloc+0xae/0xe0
kmem_cache_alloc_trace+0x191/0x350
hci_cmd_sync_queue+0x97/0x2b0
hci_update_passive_scan+0x176/0x1d0
le_conn_complete_evt+0x1b5/0x1a00
hci_le_conn_complete_evt+0x234/0x340
hci_le_meta_evt+0x231/0x4e0
hci_event_packet+0x4c5/0xf00
hci_rx_work+0x37d/0x880
process_one_work+0x77b/0x11c0
worker_thread+0x544/0x1180
kthread+0x285/0x320
ret_from_fork+0x22/0x30
Freed by task 269:
kasan_save_stack+0x26/0x50
kasan_set_track+0x25/0x40
kasan_set_free_info+0x24/0x40
____kasan_slab_free+0x176/0x1c0
__kasan_slab_free+0x12/0x20
slab_free_freelist_hook+0x95/0x1a0
kfree+0xba/0x2f0
hci_cmd_sync_clear+0x14c/0x210
hci_unregister_dev+0xff/0x440
vhci_release+0x7b/0xf0
__fput+0x1f3/0x970
____fput+0xe/0x20
task_work_run+0xd4/0x160
do_exit+0x8b0/0x22a0
do_group_exit+0xba/0x2a0
get_signal+0x1e4a/0x25b0
arch_do_signal_or_restart+0x93/0x1f80
exit_to_user_mode_prepare+0xf5/0x1a0
syscall_exit_to_user_mode+0x26/0x50
ret_from_fork+0x15/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
device_add shall not be called multiple times as stated in its
documentation:
'Do not call this routine or device_register() more than once for
any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
<TASK>
__list_add include/linux/list.h:69 [inline]
list_add_tail include/linux/list.h:102 [inline]
kobj_kset_join lib/kobject.c:164 [inline]
kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214
kobject_add_varg lib/kobject.c:358 [inline]
kobject_add+0x150/0x1c0 lib/kobject.c:410
device_add+0x368/0x1e90 drivers/base/core.c:3452
hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53
hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799
hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110
hci_event_func net/bluetooth/hci_event.c:7440 [inline]
hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495
hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007
process_one_work+0x991/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix user-after-free
This uses l2cap_chan_hold_unless_zero() after calling
__l2cap_get_chan_blah() to prevent the following trace:
Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref
*kref)
Bluetooth: chan 0000000023c4974d
Bluetooth: parent 00000000ae861c08
==================================================================
BUG: KASAN: use-after-free in __mutex_waiter_is_first
kernel/locking/mutex.c:191 [inline]
BUG: KASAN: use-after-free in __mutex_lock_common
kernel/locking/mutex.c:671 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400
kernel/locking/mutex.c:729
Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()
syzbot is again reporting attempt to cancel uninitialized work
at mgmt_index_removed() [1], for setting of HCI_MGMT flag from
mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can
race with testing of HCI_MGMT flag from mgmt_index_removed() from
hci_sock_bind() due to lack of serialization via hci_dev_lock().
Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can
safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and
hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag
after INIT_DELAYED_WORK() completed.
This is a local fix based on mgmt_chan_list_lock. Lack of serialization
via hci_dev_lock() might be causing different race conditions somewhere
else. But a global fix based on hci_dev_lock() should deserve a future
patch. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
ret_from_fork (arch/x86/entry/entry_64.S:306)
</TASK>
Allocated by task 43169:
kasan_save_stack (mm/kasan/common.c:39)
__kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
__alloc_skb (net/core/skbuff.c:414)
l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
process_one_work (kernel/workqueue.c:2289)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
kthread (kernel/kthread.c:376)
ret_from_fork (arch/x86/entry/entry_64.S:306)
Freed by task 27920:
kasan_save_stack (mm/kasan/common.c:39)
kasan_set_track (mm/kasan/common.c:45)
kasan_set_free_info (mm/kasan/generic.c:372)
____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
slab_free_freelist_hook (mm/slub.c:1780)
kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
sock_read_iter (net/socket.c:1087)
new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
vfs_read (fs/read_write.c:482)
ksys_read (fs/read_write.c:620)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Use del_timer_sync() before freeing
While looking at a crash report on a timer list being corrupted, which
usually happens when a timer is freed while still active. This is
commonly triggered by code calling del_timer() instead of
del_timer_sync() just before freeing.
One possible culprit is the hci_qca driver, which does exactly that.
Eric mentioned that wake_retrans_timer could be rearmed via the work
queue, so also move the destruction of the work queue before
del_timer_sync(). |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event
We should not access skb buffer data anymore after hci_recv_frame was
called.
[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0
[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker
[ 39.634962] Call trace:
[ 39.634974] dump_backtrace+0x0/0x3b8
[ 39.634999] show_stack+0x20/0x2c
[ 39.635016] dump_stack_lvl+0x60/0x78
[ 39.635040] print_address_description+0x70/0x2f0
[ 39.635062] kasan_report+0x154/0x194
[ 39.635079] __asan_report_load1_noabort+0x44/0x50
[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4
[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4
[ 39.635157] process_one_work+0x560/0xc5c
[ 39.635177] worker_thread+0x7ec/0xcc0
[ 39.635195] kthread+0x2d0/0x3d0
[ 39.635215] ret_from_fork+0x10/0x20
[ 39.635247] Allocated by task 0:
[ 39.635260] (stack is not available)
[ 39.635281] Freed by task 2392:
[ 39.635295] kasan_save_stack+0x38/0x68
[ 39.635319] kasan_set_track+0x28/0x3c
[ 39.635338] kasan_set_free_info+0x28/0x4c
[ 39.635357] ____kasan_slab_free+0x104/0x150
[ 39.635374] __kasan_slab_free+0x18/0x28
[ 39.635391] slab_free_freelist_hook+0x114/0x248
[ 39.635410] kfree+0xf8/0x2b4
[ 39.635427] skb_free_head+0x58/0x98
[ 39.635447] skb_release_data+0x2f4/0x410
[ 39.635464] skb_release_all+0x50/0x60
[ 39.635481] kfree_skb+0xc8/0x25c
[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth]
[ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth]
[ 39.635925] process_one_work+0x560/0xc5c
[ 39.635951] worker_thread+0x7ec/0xcc0
[ 39.635970] kthread+0x2d0/0x3d0
[ 39.635990] ret_from_fork+0x10/0x20
[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600
which belongs to the cache kmalloc-512 of size 512
[ 39.636039] The buggy address is located 13 bytes inside of
512-byte region [ffffff80cf28a600, ffffff80cf28a800) |
