From: "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>
To: Pauli Virtanen <pav@iki.fi>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: Fix UAF for hci_chan
Date: Sun, 8 Oct 2023 19:49:23 +0800 [thread overview]
Message-ID: <8266e59c-0819-b477-7eff-c4bdfb5614de@huawei.com> (raw)
In-Reply-To: <f1b9fe3939dff426528760eca39d4ad4ab2340a3.camel@iki.fi>
> Hi,
>
> la, 2023-10-07 kello 17:35 +0800, Ziyang Xuan kirjoitti:
>> Syzbot reports a UAF problem as follows:
>>
>> BUG: KASAN: slab-use-after-free in hci_send_acl+0x48/0xe70 net/bluetooth/hci_core.c:3231
>> ...
>> Call Trace:
>> <TASK>
>> __dump_stack lib/dump_stack.c:88 [inline]
>> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
>> print_address_description mm/kasan/report.c:364 [inline]
>> print_report+0x163/0x540 mm/kasan/report.c:475
>> kasan_report+0x175/0x1b0 mm/kasan/report.c:588
>> hci_send_acl+0x48/0xe70 net/bluetooth/hci_core.c:3231
>> l2cap_send_conn_req net/bluetooth/l2cap_core.c:1286 [inline]
>> l2cap_start_connection+0x465/0x620 net/bluetooth/l2cap_core.c:1514
>> l2cap_conn_start+0xbf3/0x1130 net/bluetooth/l2cap_core.c:1661
>> process_one_work kernel/workqueue.c:2630 [inline]
>> process_scheduled_works+0x90f/0x1400 kernel/workqueue.c:2703
>> worker_thread+0xa5f/0xff0 kernel/workqueue.c:2784
>> kthread+0x2d3/0x370 kernel/kthread.c:388
>> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
>> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>> </TASK>
>
> Note this looks like the same issue as in the following thread, where
> there's a suggestion from maintainer:
>
> https://lore.kernel.org/linux-bluetooth/fd9c0f0eddb8a7d73e9797568dc3cf2bc9b8ad62.1696077070.git.pav@iki.fi/T/#u
>
>
> Is it the same issue?
Yes, Thank you for your reminder.
I think use ida to make handle unique can solve the problem more easily.
I will rebase my patch.
Ziyang Xuan
>
>>
>> Allocated by task 27110:
>> kasan_save_stack mm/kasan/common.c:45 [inline]
>> kasan_set_track+0x4f/0x70 mm/kasan/common.c:52
>> ____kasan_kmalloc mm/kasan/common.c:374 [inline]
>> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:383
>> kmalloc include/linux/slab.h:599 [inline]
>> kzalloc include/linux/slab.h:720 [inline]
>> hci_chan_create+0xc8/0x300 net/bluetooth/hci_conn.c:2714
>> l2cap_conn_add+0x69/0xc10 net/bluetooth/l2cap_core.c:7841
>> l2cap_chan_connect+0x61f/0xeb0 net/bluetooth/l2cap_core.c:8053
>> bt_6lowpan_connect net/bluetooth/6lowpan.c:894 [inline]
>> lowpan_control_write+0x55e/0x850 net/bluetooth/6lowpan.c:1129
>> full_proxy_write+0x113/0x1c0 fs/debugfs/file.c:236
>> vfs_write+0x286/0xaf0 fs/read_write.c:582
>> ksys_write+0x1a0/0x2c0 fs/read_write.c:637
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>
>> Freed by task 5067:
>> kasan_save_stack mm/kasan/common.c:45 [inline]
>> kasan_set_track+0x4f/0x70 mm/kasan/common.c:52
>> kasan_save_free_info+0x28/0x40 mm/kasan/generic.c:522
>> ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
>> kasan_slab_free include/linux/kasan.h:164 [inline]
>> slab_free_hook mm/slub.c:1800 [inline]
>> slab_free_freelist_hook mm/slub.c:1826 [inline]
>> slab_free mm/slub.c:3809 [inline]
>> __kmem_cache_free+0x25f/0x3b0 mm/slub.c:3822
>> hci_chan_list_flush net/bluetooth/hci_conn.c:2754 [inline]
>> hci_conn_cleanup net/bluetooth/hci_conn.c:152 [inline]
>> hci_conn_del+0x4f8/0xc40 net/bluetooth/hci_conn.c:1156
>> hci_abort_conn_sync+0xa45/0xfe0
>> hci_cmd_sync_work+0x228/0x400 net/bluetooth/hci_sync.c:306
>> process_one_work kernel/workqueue.c:2630 [inline]
>> process_scheduled_works+0x90f/0x1400 kernel/workqueue.c:2703
>> worker_thread+0xa5f/0xff0 kernel/workqueue.c:2784
>> kthread+0x2d3/0x370 kernel/kthread.c:388
>> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
>> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
>>
>> There are two main reasons for this:
>> 1. In the case of hci_conn_add() concurrency, the handle of
>> hci_conn allocated through hci_conn_hash_alloc_unset() is not unique.
>> 2. The processes related to hci_abort_conn() and hci_connect_xxx()
>> can be concurrent, but the two processes lack synchronization.
>>
>> To fix this, use ida to manage the allocation of conn->handle, and
>> add the HCI_CONN_DISC flag to achieve synchronization between
>> hci_abort_conn() and hci_connect_xxx() related processes.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
prev parent reply other threads:[~2023-10-08 12:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-07 9:35 Ziyang Xuan
2023-10-07 10:44 ` Pauli Virtanen
2023-10-08 11:49 ` Ziyang Xuan (William) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8266e59c-0819-b477-7eff-c4bdfb5614de@huawei.com \
--to=william.xuanziyang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pav@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®