Message-ID: <CAFRLqsUE84wW0JKbsh6Lw0USQbnCbokXd3PANc+4i_nsnEUMYA@mail.gmail.com>
Date: Fri, 12 Sep 2025 23:59:06 +0800
From: cen zhang <zzzccc427@...il.com>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: johan.hedberg@...il.com, marcel@...tmann.org, linux-kernel@...r.kernel.org, 
	baijiaju1990@...il.com, zhenghaoran154@...il.com, r33s3n6@...il.com, 
	linux-bluetooth@...r.kernel.org, "gality369@...il.com" <gality369@...il.com>
Subject: Re: [BUG]: slab-use-after-free Read in mgmt_set_powered_complete

Hi Luiz,

Thank you for your quick response and the important clarification
about hci_cmd_sync_dequeue().

You are absolutely correct - I was indeed referring to the TOCTOU
problem in pending_find(), not the -ECANCELED check. The
hci_cmd_sync_dequeue() call in cmd_complete_rsp() is a crucial detail
that I initially overlooked in my analysis.

After examining the code more carefully, I can see that while
hci_cmd_sync_dequeue() does attempt to remove pending sync commands
from the queue, but it cannot prevent the race condition we're seeing.
The fundamental issue is that hci_cmd_sync_dequeue() can only remove
work items that are still queued, but cannot stop work items that are
already executing or about to execute their completion callbacks.

The race window occurs when:
1. mgmt_set_powered_complete() is about to execute (work item has been dequeued)
2. mgmt_index_removed() -> mgmt_pending_foreach() -> cmd_complete_rsp() executes
3. hci_cmd_sync_dequeue() removes queued items but cannot affect the
already-running callback
4. mgmt_pending_free() frees the cmd object
5. mgmt_set_powered_complete() still executes and accesses freed cmd->param

I am sorry that I haven't get a reliable reproducer from syzkaller for
this bug may be due to it is timing-sensitive.


Best regards,
Cen Zhang

Luiz Augusto von Dentz <luiz.dentz@...il.com> 于2025年9月12日周五 22:27写道：
>
> Hi Cen,
>
> On Fri, Sep 12, 2025 at 8:34 AM cen zhang <zzzccc427@...il.com> wrote:
> >
> > Hello maintainers,
> >
> > I would like to report  a use-after-free (UAF) vulnerability
> > found in the Bluetooth management subsystem using our
> > customized syzkaller on 6.17.0-rc5.
> > The bug occurs due to a race condition between HCI command completion
> > callbacks and HCI socket bind operations that trigger device cleanup.
> >
> > After my superficial analysis, the situation when race occurs may be as follows:
> >
> > PATH 1 - SET_POWERED Command Execution:
> > 1. User space application sends MGMT_OP_SET_POWERED command via HCI
> > management socket
> > 2. set_powered() function creates mgmt_pending_cmd object via mgmt_pending_add()
> > 3. Command is submitted to HCI work queue via
> > hci_cmd_sync_submit()/hci_cmd_sync_queue()
> > 4. Work queue executes set_powered_sync() followed by
> > mgmt_set_powered_complete() callback
> > 5. mgmt_set_powered_complete() attempts to access cmd->param (line 1342)
> >
> > PATH 2 - HCI Socket Bind Cleanup:
> > 1. Another process attempts to bind HCI socket with HCI_CHANNEL_USER mode
> > 2. hci_sock_bind() calls mgmt_index_removed() to clean up management state
> > 3. mgmt_index_removed() calls mgmt_pending_foreach(0, hdev, true, ...)
> > 4. All pending commands are removed and freed, including the
> > SET_POWERED command object
>
> It doesn't only do that it also does:
>
>     /* dequeue cmd_sync entries using cmd as data as that is about to be
>      * removed/freed.
>      */
>     hci_cmd_sync_dequeue(match->hdev, NULL, cmd, NULL);
>
> > 5. The mgmt_pending_cmd object and its cmd->param are freed via
> > mgmt_pending_free()
> >
> > RACE CONDITION:
> > The issue occurs when PATH 2 executes between the time PATH 1 submits
> > the command
> > to the work queue and when the completion callback accesses
> > cmd->param. The current
> > protection mechanism in mgmt_set_powered_complete() has a TOCTOU
> > (Time-of-Check-to-Time-of-Use) flaw:
> >
> >     if (err == -ECANCELED || cmd != pending_find(MGMT_OP_SET_POWERED, hdev))
> >         return;
>
> i guess you are talking about pending_find not -ECANCELED having
> TOCTOU problem, do you have a reproducer that I can test with?
>
> >
> >     cp = cmd->param;  // <-- USE-AFTER-FREE occurs here
> >
> > The check allowing the cmd object to be freed between
> > the validation and the actual memory access.
> >
> > The detail KASAN report as follow:
> >
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in
> > mgmt_set_powered_complete+0x83d/0xf10 net/bluetooth/mgmt.c:1342
> > Read of size 8 at addr ffff88810edd90b0 by task kworker/u17:3/811
> >
> > CPU: 0 UID: 0 PID: 811 Comm: kworker/u17:3 Not tainted
> > 6.17.0-rc5-ge5bbb70171d1 #7 PREEMPT(voluntary)
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> > Workqueue: hci0 hci_cmd_sync_work
> > Call Trace:
> >  <TASK>
> >  __dump_stack lib/dump_stack.c:94 [inline]
> >  dump_stack_lvl+0xca/0x130 lib/dump_stack.c:120
> >  print_address_description mm/kasan/report.c:378 [inline]
> >  print_report+0x171/0x7f0 mm/kasan/report.c:482
> >  kasan_report+0x139/0x170 mm/kasan/report.c:595
> >  mgmt_set_powered_complete+0x83d/0xf10 net/bluetooth/mgmt.c:1342
> >  hci_cmd_sync_work+0x8df/0xaf0 net/bluetooth/hci_sync.c:334
> >  process_one_work kernel/workqueue.c:3236 [inline]
> >  process_scheduled_works+0x7a8/0x1030 kernel/workqueue.c:3319
> >  worker_thread+0xb97/0x11d0 kernel/workqueue.c:3400
> >  kthread+0x3d4/0x800 kernel/kthread.c:463
> >  ret_from_fork+0x13b/0x1e0 arch/x86/kernel/process.c:148
> >  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> >  </TASK>
> >
> > Allocated by task 197:
> >  kasan_save_stack mm/kasan/common.c:47 [inline]
> >  kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
> >  poison_kmalloc_redzone mm/kasan/common.c:388 [inline]
> >  __kasan_kmalloc+0x72/0x90 mm/kasan/common.c:405
> >  kmalloc_noprof include/linux/slab.h:905 [inline]
> >  kzalloc_noprof include/linux/slab.h:1039 [inline]
> >  mgmt_pending_new+0xcd/0x580 net/bluetooth/mgmt_util.c:269
> >  mgmt_pending_add+0x54/0x410 net/bluetooth/mgmt_util.c:296
> >  set_powered+0x8c6/0xea0 net/bluetooth/mgmt.c:1407
> >  hci_mgmt_cmd+0x1ee4/0x33f0 net/bluetooth/hci_sock.c:1719
> >  hci_sock_sendmsg+0xcb0/0x2510 net/bluetooth/hci_sock.c:1839
> >  sock_sendmsg_nosec net/socket.c:714 [inline]
> >  __sock_sendmsg+0x21c/0x270 net/socket.c:729
> >  sock_write_iter+0x1b7/0x250 net/socket.c:1179
> >  do_iter_readv_writev+0x598/0x760
> >  vfs_writev+0x3c8/0xd20 fs/read_write.c:1057
> >  do_writev+0x105/0x270 fs/read_write.c:1103
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xd2/0x200 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Freed by task 100890:
> >  kasan_save_stack mm/kasan/common.c:47 [inline]
> >  kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
> >  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576
> >  poison_slab_object mm/kasan/common.c:243 [inline]
> >  __kasan_slab_free+0x41/0x50 mm/kasan/common.c:275
> >  kasan_slab_free include/linux/kasan.h:233 [inline]
> >  slab_free_hook mm/slub.c:2428 [inline]
> >  slab_free mm/slub.c:4701 [inline]
> >  kfree+0x189/0x390 mm/slub.c:4900
> >  mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]
> >  mgmt_pending_foreach+0x6c4/0x8a0 net/bluetooth/mgmt_util.c:257
> >  mgmt_index_removed+0x164/0x530 net/bluetooth/mgmt.c:9370
> >  hci_sock_bind+0x151a/0x1f30 net/bluetooth/hci_sock.c:1314
> >  __sys_bind_socket net/socket.c:1858 [inline]
> >  __sys_bind+0x229/0x2f0 net/socket.c:1889
> >  __do_sys_bind net/socket.c:1894 [inline]
> >  __se_sys_bind net/socket.c:1892 [inline]
> >  __x64_sys_bind+0x7a/0x90 net/socket.c:1892
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xd2/0x200 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > The buggy address belongs to the object at ffff88810edd9080
> >  which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 48 bytes inside of
> >  freed 96-byte region [ffff88810edd9080, ffff88810edd90e0)
> >
> > The buggy address belongs to the physical page:
> > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10edd9
> > anon flags: 0x200000000000000(node=0|zone=2)
> > page_type: f5(slab)
> > raw: 0200000000000000 ffff888100042280 ffffea00041e07c0 dead000000000003
> > raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> >  ffff88810edd8f80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
> >  ffff88810edd9000: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > >ffff88810edd9080: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> >                                      ^
> >  ffff88810edd9100: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> >  ffff88810edd9180: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ==================================================================
> >
> > Best regards,
> > Cen Zhang
>
>
>
> --
> Luiz Augusto von Dentz

Powered by blists - more mailing lists