map[AckedBy:[] Fixes:map[AuthorEmail:hildawu@realtek.com AuthorName:Hilda Wu Hash:9e14606d8f38ea52a38c27692a9c1513c987a5da Title:Bluetooth: msft: Extended monitor tracking by address filter] KernelBranch:master KernelCommit:8d3ae59288f1e7d58d76558a6ee96d533bc5019f KernelRepo:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git PatchDescription:Bluetooth: hci_core: Fix race condition during device registration

In hci_register_dev(), the power_on work item is queued to
hdev->req_workqueue before initializing hdev->adv_monitors_idr and
registering the MSFT extension via msft_register(). For devices marked with
quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on
the device. When the power_on work item runs concurrently on another CPU,
hci_power_on() detects that the device is unconfigured and immediately
invokes hci_dev_do_close(), which calls msft_do_close().

Concurrently, msft_register() allocates the msft structure and exposes it
to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If
msft_do_close() executes while hdev->msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:

DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common
kernel/locking/mutex.c:625 [inline]
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550
kernel/locking/mutex.c:821
...
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Fix this by moving the queue_work() call in hci_register_dev() to after
idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device
structures and extensions are fully initialized before asynchronous tasks
can access them. Additionally, assign hdev->msft_data in msft_register()
only after mutex_init(&msft->filter_lock) has completed. PatchDiff:diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)
 Recipients:[map[Email:linux-bluetooth@vger.kernel.org Name: To:true] map[Email:linux-kernel@vger.kernel.org Name: To:false] map[Email:luiz.dentz@gmail.com Name:Luiz Augusto von Dentz To:true] map[Email:marcel@holtmann.org Name:Marcel Holtmann To:true] map[Email:hildawu@realtek.com Name:Hilda Wu To:true]] ReportedBy:[] ReviewedBy:[] SuggestedBy:[] TestedBy:[]]

map[KernelBranch:master KernelCommit:8d3ae59288f1e7d58d76558a6ee96d533bc5019f KernelRepo:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git]

map[SimplifiedCRepro:// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#ifndef __NR_fsconfig
#define __NR_fsconfig 431
#endif

uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	const char* reason;
	(void)reason;
				intptr_t res = 0;
	if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
//  epoll_create arguments: [
//    size: int32 = 0x628 (4 bytes)
//  ]
//  returns fd_epoll
	res = syscall(__NR_epoll_create, /*size=*/0x628);
	if (res != -1)
		r[0] = res;
//  epoll_ctl$EPOLL_CTL_ADD arguments: [
//    epfd: fd_epoll (resource)
//    op: const = 0x1 (8 bytes)
//    fd: fd (resource)
//    ev: nil
//  ]
	syscall(__NR_epoll_ctl, /*epfd=*/r[0], /*op=*/1ul, /*fd=*/(intptr_t)-1, /*ev=*/0ul);
//  ioctl$F2FS_IOC_RESIZE_FS arguments: [
//    fd: fd (resource)
//    cmd: const = 0x4008f510 (4 bytes)
//    arg: ptr[in, int64] {
//      int64 = 0x8 (8 bytes)
//    }
//  ]
*(uint64_t*)0x200000000040 = 8;
	syscall(__NR_ioctl, /*fd=*/r[0], /*cmd=*/0x4008f510, /*arg=*/0x200000000040ul);
//  socket arguments: [
//    domain: socket_domain = 0x10 (8 bytes)
//    type: socket_type = 0x3 (8 bytes)
//    proto: int32 = 0x0 (4 bytes)
//  ]
//  returns sock
	res = syscall(__NR_socket, /*domain=AF_NETLINK*/0x10ul, /*type=SOCK_RAW*/3ul, /*proto=*/0);
	if (res != -1)
		r[1] = res;
//  getsockname$packet arguments: [
//    fd: sock_packet (resource)
//    addr: nil
//    addrlen: ptr[inout, len] {
//      len = 0x0 (4 bytes)
//    }
//  ]
*(uint32_t*)0x200000000100 = 0;
	syscall(__NR_getsockname, /*fd=*/r[1], /*addr=*/0ul, /*addrlen=*/0x200000000100ul);
//  mkdirat arguments: [
//    fd: fd_dir (resource)
//    path: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 00} (length 0x6)
//    }
//    mode: open_mode = 0x1ff (8 bytes)
//  ]
memcpy((void*)0x200000000080, "./dev\000", 6);
	syscall(__NR_mkdirat, /*fd=*/0xffffff9c, /*path=*/0x200000000080ul, /*mode=S_IXOTH|S_IWOTH|S_IROTH|S_IXGRP|S_IWGRP|S_IRGRP|S_IXUSR|S_IWUSR|0x100*/0x1fful);
//  mount arguments: [
//    src: nil
//    dst: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 00} (length 0x6)
//    }
//    type: ptr[in, buffer] {
//      buffer: {64 65 76 74 6d 70 66 73 00} (length 0x9)
//    }
//    flags: mount_flags = 0x0 (8 bytes)
//    data: nil
//  ]
memcpy((void*)0x2000000000c0, "./dev\000", 6);
memcpy((void*)0x200000000100, "devtmpfs\000", 9);
	syscall(__NR_mount, /*src=*/0ul, /*dst=*/0x2000000000c0ul, /*type=*/0x200000000100ul, /*flags=*/0ul, /*data=*/0ul);
//  openat arguments: [
//    fd: fd_dir (resource)
//    file: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 2f 76 68 63 69 00} (length 0xb)
//    }
//    flags: open_flags = 0x2 (4 bytes)
//    mode: open_mode = 0x0 (2 bytes)
//  ]
//  returns fd
memcpy((void*)0x200000000140, "./dev/vhci\000", 11);
	res = syscall(__NR_openat, /*fd=*/0xffffff9c, /*file=*/0x200000000140ul, /*flags=O_RDWR*/2, /*mode=*/0);
	if (res != -1)
		r[2] = res;
//  fsconfig$FSCONFIG_CMD_CREATE arguments: [
//    fd: fd_fscontext (resource)
//    cmd: const = 0x6 (8 bytes)
//    key: const = 0x0 (8 bytes)
//    value: const = 0x0 (8 bytes)
//    aux: const = 0x0 (8 bytes)
//  ]
	syscall(__NR_fsconfig, /*fd=*/(intptr_t)-1, /*cmd=*/6ul, /*key=*/0ul, /*value=*/0ul, /*aux=*/0ul);
//  read$FUSE arguments: [
//    fd: fd_fuse (resource)
//    buf: ptr[out, fuse_in[read_buffer]] {
//      fuse_in[read_buffer] {
//        len: len = 0x2020 (4 bytes)
//        opcode: int32 = 0x0 (4 bytes)
//        unique: fuse_unique (resource)
//        uid: uid (resource)
//        gid: gid (resource)
//        pid: pid (resource)
//        padding: int32 = 0x0 (4 bytes)
//        payload: buffer: (DirOut)
//      }
//    }
//    len: bytesize = 0x2020 (8 bytes)
//  ]
	syscall(__NR_read, /*fd=*/r[2], /*buf=*/0x2000000002c0ul, /*len=*/0x2020ul);
//  write arguments: [
//    fd: fd (resource)
//    buf: ptr[in, buffer] {
//      buffer: {ff 80} (length 0x2)
//    }
//    count: len = 0x2 (8 bytes)
//  ]
memcpy((void*)0x200000000280, "\xff\x80", 2);
	syscall(__NR_write, /*fd=*/r[2], /*buf=*/0x200000000280ul, /*count=*/2ul);
	return 0;
}
]

map[KernelSrc:/app/workdir/cache/src/b5692495be56e63dd0879dd861d23f69899ae44d]

map[KernelObj:/app/workdir/cache/build/1c4c6cd51b8dc54cb91defbe8b0a37466fffae8d]

map[OtherCrashReports:<nil> ReproducedBugTitle:WARNING in msft_do_close ReproducedCrashReport:------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf
 ReproducedFaultInjection:]

map[Index:codesearch-index]

deep-reasoning

You are an experienced Linux kernel developer tasked with debugging a kernel crash root cause.
You need to provide a detailed explanation of the root cause for another developer to be
able to write a fix for the bug based on your explanation. Include all relevant details
into the response: function/struct/field/etc names, code snippets, line numbers,
macro/enum values, etc.



Don't make assumptions about the kernel source code (it may be different from what you assume it is).
Extensively use the provided code access tools (codesearch-*, git-*, grepper, etc)
to examine the actual source code, and confirm any assumptions.

Prefer calling several tools at the same time to save round-trips.

The crash is:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf


The following C code is a draft of the vulnerable syscall sequence. Keep in mind that
it may lack the precise threading, sandboxing, and some arguments of a working reproducer:

// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#ifndef __NR_fsconfig
#define __NR_fsconfig 431
#endif

uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	const char* reason;
	(void)reason;
				intptr_t res = 0;
	if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
//  epoll_create arguments: [
//    size: int32 = 0x628 (4 bytes)
//  ]
//  returns fd_epoll
	res = syscall(__NR_epoll_create, /*size=*/0x628);
	if (res != -1)
		r[0] = res;
//  epoll_ctl$EPOLL_CTL_ADD arguments: [
//    epfd: fd_epoll (resource)
//    op: const = 0x1 (8 bytes)
//    fd: fd (resource)
//    ev: nil
//  ]
	syscall(__NR_epoll_ctl, /*epfd=*/r[0], /*op=*/1ul, /*fd=*/(intptr_t)-1, /*ev=*/0ul);
//  ioctl$F2FS_IOC_RESIZE_FS arguments: [
//    fd: fd (resource)
//    cmd: const = 0x4008f510 (4 bytes)
//    arg: ptr[in, int64] {
//      int64 = 0x8 (8 bytes)
//    }
//  ]
*(uint64_t*)0x200000000040 = 8;
	syscall(__NR_ioctl, /*fd=*/r[0], /*cmd=*/0x4008f510, /*arg=*/0x200000000040ul);
//  socket arguments: [
//    domain: socket_domain = 0x10 (8 bytes)
//    type: socket_type = 0x3 (8 bytes)
//    proto: int32 = 0x0 (4 bytes)
//  ]
//  returns sock
	res = syscall(__NR_socket, /*domain=AF_NETLINK*/0x10ul, /*type=SOCK_RAW*/3ul, /*proto=*/0);
	if (res != -1)
		r[1] = res;
//  getsockname$packet arguments: [
//    fd: sock_packet (resource)
//    addr: nil
//    addrlen: ptr[inout, len] {
//      len = 0x0 (4 bytes)
//    }
//  ]
*(uint32_t*)0x200000000100 = 0;
	syscall(__NR_getsockname, /*fd=*/r[1], /*addr=*/0ul, /*addrlen=*/0x200000000100ul);
//  mkdirat arguments: [
//    fd: fd_dir (resource)
//    path: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 00} (length 0x6)
//    }
//    mode: open_mode = 0x1ff (8 bytes)
//  ]
memcpy((void*)0x200000000080, "./dev\000", 6);
	syscall(__NR_mkdirat, /*fd=*/0xffffff9c, /*path=*/0x200000000080ul, /*mode=S_IXOTH|S_IWOTH|S_IROTH|S_IXGRP|S_IWGRP|S_IRGRP|S_IXUSR|S_IWUSR|0x100*/0x1fful);
//  mount arguments: [
//    src: nil
//    dst: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 00} (length 0x6)
//    }
//    type: ptr[in, buffer] {
//      buffer: {64 65 76 74 6d 70 66 73 00} (length 0x9)
//    }
//    flags: mount_flags = 0x0 (8 bytes)
//    data: nil
//  ]
memcpy((void*)0x2000000000c0, "./dev\000", 6);
memcpy((void*)0x200000000100, "devtmpfs\000", 9);
	syscall(__NR_mount, /*src=*/0ul, /*dst=*/0x2000000000c0ul, /*type=*/0x200000000100ul, /*flags=*/0ul, /*data=*/0ul);
//  openat arguments: [
//    fd: fd_dir (resource)
//    file: ptr[in, buffer] {
//      buffer: {2e 2f 64 65 76 2f 76 68 63 69 00} (length 0xb)
//    }
//    flags: open_flags = 0x2 (4 bytes)
//    mode: open_mode = 0x0 (2 bytes)
//  ]
//  returns fd
memcpy((void*)0x200000000140, "./dev/vhci\000", 11);
	res = syscall(__NR_openat, /*fd=*/0xffffff9c, /*file=*/0x200000000140ul, /*flags=O_RDWR*/2, /*mode=*/0);
	if (res != -1)
		r[2] = res;
//  fsconfig$FSCONFIG_CMD_CREATE arguments: [
//    fd: fd_fscontext (resource)
//    cmd: const = 0x6 (8 bytes)
//    key: const = 0x0 (8 bytes)
//    value: const = 0x0 (8 bytes)
//    aux: const = 0x0 (8 bytes)
//  ]
	syscall(__NR_fsconfig, /*fd=*/(intptr_t)-1, /*cmd=*/6ul, /*key=*/0ul, /*value=*/0ul, /*aux=*/0ul);
//  read$FUSE arguments: [
//    fd: fd_fuse (resource)
//    buf: ptr[out, fuse_in[read_buffer]] {
//      fuse_in[read_buffer] {
//        len: len = 0x2020 (4 bytes)
//        opcode: int32 = 0x0 (4 bytes)
//        unique: fuse_unique (resource)
//        uid: uid (resource)
//        gid: gid (resource)
//        pid: pid (resource)
//        padding: int32 = 0x0 (4 bytes)
//        payload: buffer: (DirOut)
//      }
//    }
//    len: bytesize = 0x2020 (8 bytes)
//  ]
	syscall(__NR_read, /*fd=*/r[2], /*buf=*/0x2000000002c0ul, /*len=*/0x2020ul);
//  write arguments: [
//    fd: fd (resource)
//    buf: ptr[in, buffer] {
//      buffer: {ff 80} (length 0x2)
//    }
//    count: len = 0x2 (8 bytes)
//  ]
memcpy((void*)0x200000000280, "\xff\x80", 2);
	syscall(__NR_write, /*fd=*/r[2], /*buf=*/0x200000000280ul, /*count=*/2ul);
	return 0;
}

This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```

gemini-3.1-pro-preview

							input: 7862
							output: 36
							thoughts: 319
						

**Kernel Crash Analysis**

Okay, so we've got a kernel crash, specifically a `DEBUG_LOCKS_WARN_ON` triggered by a mutex issue. The error message points to `kernel/locking/mutex.c:625` – classic mutex corruption. Looks like we're hitting it during a `__mutex_lock_common` call. The CPU context is `kworker/u11:2/5607`, which immediately tells me this is happening in a kernel worker thread, likely asynchronous.

The call trace is the key. It looks like the problem is stemming from a close operation, specifically within the Microsoft Bluetooth stack: `msft_do_close` which is calling `hci_dev_close_sync`, which in turn seems to be calling `hci_dev_do_close`. Eventually we get into `hci_power_on`. So, something in this close sequence is corrupting the mutex. My initial thought is a double-free or use-after-free scenario, perhaps with the mutex being incorrectly handled in `msft_do_close`. I need to dig into the code, and my first point of call is `msft_do_close` in `net/bluetooth/msft.c:693`.

map[File:net/bluetooth/msft.c FirstLine:670 LineCount:50]

map[Contents: 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
 700:	
 701:		hci_dev_lock(hdev);
 702:	
 703:		/* Clear any devices that are being monitored and notify device lost */
 704:		hdev->advmon_pend_notify = false;
 705:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 706:	
 707:		hci_dev_unlock(hdev);
 708:	}
 709:	
 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
 715:		struct sk_buff *skb;
 716:		int err = 0;
 717:	
 718:		if (!msft) {
 719:			bt_dev_err(hdev, "MSFT: msft data is freed");
]

gemini-3.1-pro-preview

							input: 9299
							output: 53
							thoughts: 79
						

**Debugging a Kernel Lock Issue**

Okay, so I've got a crash, and it's pinpointed to `mutex_lock(&msft->filter_lock)` within `msft_do_close`. Not good. The warning, `DEBUG_LOCKS_WARN_ON(lock->magic != lock)`, is screaming "mutex problem!" This usually means the mutex hasn't been initialized, it's been freed, or somehow got corrupted. Time to dig in and trace the lifecycle of this `msft` structure. I need to figure out exactly where `msft` is allocated, and critically, *how* `filter_lock` is being initialized. This is almost certainly the root of the issue. Let's see if the initialization is missing or if there's a use-after-free scenario at play. Time to get the gdb set up.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:0 Name:msft_data SourceTreePrefix:net/bluetooth/]

map[References:[map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_add_address_filter SourceFile:net/bluetooth/msft.c SourceLine:932] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_add_address_filter_sync SourceFile:net/bluetooth/msft.c SourceLine:838] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_add_monitor_pattern SourceFile:net/bluetooth/msft.c SourceLine:1154] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_cancel_address_filter_sync SourceFile:net/bluetooth/msft.c SourceLine:714] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_do_close SourceFile:net/bluetooth/msft.c SourceLine:669] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_do_open SourceFile:net/bluetooth/msft.c SourceLine:633] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_find_address_data SourceFile:net/bluetooth/msft.c SourceLine:215] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_find_handle_data SourceFile:net/bluetooth/msft.c SourceLine:197] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_get_features SourceFile:net/bluetooth/msft.c SourceLine:1118] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_le_cancel_monitor_advertisement_cb SourceFile:net/bluetooth/msft.c SourceLine:373] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_le_monitor_advertisement_cb SourceFile:net/bluetooth/msft.c SourceLine:264] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_le_set_advertisement_filter_enable_cb SourceFile:net/bluetooth/msft.c SourceLine:1128] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_monitor_device_evt SourceFile:net/bluetooth/msft.c SourceLine:977] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_register SourceFile:net/bluetooth/msft.c SourceLine:755] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_release SourceFile:net/bluetooth/msft.c SourceLine:773] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_remove_addr_filters_sync SourceFile:net/bluetooth/msft.c SourceLine:307] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_remove_monitor SourceFile:net/bluetooth/msft.c SourceLine:1168] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_resume_sync SourceFile:net/bluetooth/msft.c SourceLine:610] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_set_filter_enable SourceFile:net/bluetooth/msft.c SourceLine:1182] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_suspend_sync SourceFile:net/bluetooth/msft.c SourceLine:451] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:msft_vendor_evt SourceFile:net/bluetooth/msft.c SourceLine:1070] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:read_supported_features SourceFile:net/bluetooth/msft.c SourceLine:142] map[ReferenceKind:uses ReferencingEntityKind:function ReferencingEntityName:reregister_monitor SourceFile:net/bluetooth/msft.c SourceLine:585]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 10855
							output: 36
							thoughts: 29
						

Here's my take on those functions, based on a quick glance:

**Diving into `net/bluetooth/msft.c`**

Okay, so I'm focusing on `msft_register` and `msft_release` within the Microsoft-specific Bluetooth driver code. Given my expertise, I'm already anticipating these are probably going to be pretty straightforward registration and release functions for the Microsoft-specific features within the stack. They're likely handling the initialization and cleanup of any resources tied to Microsoft's extensions or profiles that this driver supports.

`msft_register` is the one I need to pay closest attention to first. I expect it's going to involve setting up any necessary data structures, possibly registering with the Bluetooth core in some way, and maybe handling some initial handshake or capability exchange with the Microsoft-specific device. I wonder what kind of device info is being passed? Is it registering a whole stack, or just specific profiles? It’ll tell me a lot about how cleanly the Microsoft support is integrated into the mainline Bluetooth stack.

Then, with `msft_release`, I'm figuring this is the cleanup crew. Releasing any acquired resources, unregistering with the Bluetooth core, and generally ensuring a clean shutdown when the Microsoft functionality is no longer needed. I'll need to see if it’s handling any potential race conditions during release, and how robust the error handling is. A well-written release function is just as important as the registration, to avoid any memory leaks or resource deadlocks. My initial goal is to understand the fundamental lifecycle these functions define for Microsoft-specific Bluetooth support, and then I'll drill down to figure out any nuances.

map[File:net/bluetooth/msft.c FirstLine:750 LineCount:50]

map[Contents: 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
 780:		hdev->msft_data = NULL;
 781:	
 782:		kfree(msft->evt_prefix);
 783:		mutex_destroy(&msft->filter_lock);
 784:		kfree(msft);
 785:	}
 786:	
 787:	/* This function requires the caller holds hdev->lock */
 788:	static void msft_device_found(struct hci_dev *hdev, bdaddr_t *bdaddr,
 789:				      __u8 addr_type, __u16 mgmt_handle)
 790:	{
 791:		struct monitored_device *dev;
 792:	
 793:		dev = kmalloc_obj(*dev);
 794:		if (!dev) {
 795:			bt_dev_err(hdev, "MSFT vendor event %u: no memory",
 796:				   MSFT_EV_LE_MONITOR_DEVICE);
 797:			return;
 798:		}
 799:	
]

gemini-3.1-pro-preview

							input: 11973
							output: 108
							thoughts: 205
						

**Analyzing the `msft` Resource Management**

Okay, so I'm looking at this `msft` structure and its lifecycle. `msft_register` is responsible for allocating and initializing `msft`, along with the `filter_lock` associated with it, which is standard practice. `msft_release` then handles the cleanup: freeing the `msft` memory and destroying the `filter_lock`. The potential issue that's immediately jumping out at me is the classic use-after-free scenario. If `msft_do_close` is called *after* `msft_release`, it's going to try and access a memory location that's no longer valid – a guaranteed crash. Even more concerning, a concurrent call to `msft_do_close` with `msft_release` could create a race condition, where the access becomes dependent on timing and could become inconsistent.

Wait a second, there's a sanity check! `msft_do_close` includes `if (!msft) return;`. Okay, that's promising; it's explicitly checking for a null pointer before attempting to do anything. If `msft_release` sets `hdev->msft_data = NULL;`, then `msft_do_close` will see `NULL` if called after the `msft_release` call. But, there is still the concurrent access case, where `msft_do_close` could see a valid, non-NULL pointer, but `msft_release` could free it out from under it. That's still a race, and could lead to corruption or even a crash if the timing is wrong.

Now I need to understand the calling contexts. Time to dig into where `msft_release` and `msft_do_close` are called from. I need to be sure the checks are sufficient and if any of the assumptions made about the null check are valid given the use of the `msft` object throughout.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:0 Name:msft_release SourceTreePrefix:net/bluetooth/]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_release_dev SourceFile:net/bluetooth/hci_core.c SourceLine:2731]] TruncatedOutput:false]

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:0 Name:msft_do_close SourceTreePrefix:net/bluetooth/]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_dev_close_sync SourceFile:net/bluetooth/hci_sync.c SourceLine:5522]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 12855
							output: 76
							thoughts: 60
						

Here's my analysis of those function calls:

**Tracing Resource Release in the HCI Device Lifecycle**

Okay, so I'm looking at the resource cleanup sequence for these HCI devices. I see that `msft_do_close` is initiated by a call from `hci_dev_close_sync`. That's the device's synchronous closing function, so it makes sense that the Microsoft-specific closing routine (`msft_do_close`) would be triggered from there. It's likely handling cleanup tasks specific to the Microsoft implementation or associated drivers. Now, I should double check to see if there is any overlap in resource release between that and the HCI core itself.

Then, there's `msft_release` – that's called from `hci_release_dev`. `hci_release_dev`, I assume, is the standard HCI device release function. That makes perfect sense. The Microsoft-specific release function would be called as part of the more general cleanup process when the device is fully released. It sounds like `hci_release_dev` is the final step, and `msft_release` is specifically handling Microsoft-related cleanup before the HCI device is destroyed. I need to dive deeper into `hci_dev_close_sync` and `hci_release_dev` to understand the exact sequence, what resources they are freeing, and make sure there are no leaks. Let me get into those and see if anything jumps out.

map[File:net/bluetooth/hci_sync.c FirstLine:5500 LineCount:50]

map[Contents:5500:	
5501:		hci_dev_lock(hdev);
5502:	
5503:		hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
5504:	
5505:		auto_off = hci_dev_test_and_clear_flag(hdev, HCI_AUTO_OFF);
5506:	
5507:		if (!auto_off && !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) &&
5508:		    hci_dev_test_flag(hdev, HCI_MGMT))
5509:			__mgmt_power_off(hdev);
5510:	
5511:		hci_inquiry_cache_flush(hdev);
5512:		hci_pend_le_actions_clear(hdev);
5513:		hci_conn_hash_flush(hdev);
5514:		/* Prevent data races on hdev->smp_data or hdev->smp_bredr_data */
5515:		smp_unregister(hdev);
5516:		hci_dev_unlock(hdev);
5517:	
5518:		hci_sock_dev_event(hdev, HCI_DEV_DOWN);
5519:	
5520:		if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
5521:			aosp_do_close(hdev);
5522:			msft_do_close(hdev);
5523:		}
5524:	
5525:		if (hdev->flush)
5526:			hdev->flush(hdev);
5527:	
5528:		/* Reset device */
5529:		skb_queue_purge(&hdev->cmd_q);
5530:		atomic_set(&hdev->cmd_cnt, 1);
5531:		hdev->acl_cnt = 0;
5532:		hdev->sco_cnt = 0;
5533:		hdev->le_cnt = 0;
5534:		hdev->iso_cnt = 0;
5535:		if (hci_test_quirk(hdev, HCI_QUIRK_RESET_ON_CLOSE) &&
5536:		    !auto_off && !hci_dev_test_flag(hdev, HCI_UNCONFIGURED)) {
5537:			set_bit(HCI_INIT, &hdev->flags);
5538:			hci_reset_sync(hdev);
5539:			clear_bit(HCI_INIT, &hdev->flags);
5540:		}
5541:	
5542:		/* flush cmd  work */
5543:		flush_work(&hdev->cmd_work);
5544:	
5545:		/* Drop queues */
5546:		skb_queue_purge(&hdev->rx_q);
5547:		skb_queue_purge(&hdev->cmd_q);
5548:		skb_queue_purge(&hdev->raw_q);
5549:	
]

map[File:net/bluetooth/hci_core.c FirstLine:2700 LineCount:50]

map[Contents:2700:		/* Actual cleanup is deferred until hci_release_dev(). */
2701:		hci_dev_put(hdev);
2702:	}
2703:	EXPORT_SYMBOL(hci_unregister_dev);
2704:	
2705:	/* Release HCI device */
2706:	void hci_release_dev(struct hci_dev *hdev)
2707:	{
2708:		debugfs_remove_recursive(hdev->debugfs);
2709:		kfree_const(hdev->hw_info);
2710:		kfree_const(hdev->fw_info);
2711:	
2712:		destroy_workqueue(hdev->workqueue);
2713:		destroy_workqueue(hdev->req_workqueue);
2714:	
2715:		hci_dev_lock(hdev);
2716:		hci_bdaddr_list_clear(&hdev->reject_list);
2717:		hci_bdaddr_list_clear(&hdev->accept_list);
2718:		hci_uuids_clear(hdev);
2719:		hci_link_keys_clear(hdev);
2720:		hci_smp_ltks_clear(hdev);
2721:		hci_smp_irks_clear(hdev);
2722:		hci_remote_oob_data_clear(hdev);
2723:		hci_adv_instances_clear(hdev);
2724:		hci_adv_monitors_clear(hdev);
2725:		hci_bdaddr_list_clear(&hdev->le_accept_list);
2726:		hci_bdaddr_list_clear(&hdev->le_resolv_list);
2727:		hci_conn_params_clear_all(hdev);
2728:		hci_discovery_filter_clear(hdev);
2729:		hci_blocked_keys_clear(hdev);
2730:		hci_codec_list_clear(&hdev->local_codecs);
2731:		msft_release(hdev);
2732:		hci_dev_unlock(hdev);
2733:	
2734:		ida_destroy(&hdev->unset_handle_ida);
2735:		ida_free(&hci_index_ida, hdev->id);
2736:		kfree_skb(hdev->sent_cmd);
2737:		kfree_skb(hdev->req_skb);
2738:		kfree_skb(hdev->recv_event);
2739:		kfree(hdev);
2740:	}
2741:	EXPORT_SYMBOL(hci_release_dev);
2742:	
2743:	int hci_register_suspend_notifier(struct hci_dev *hdev)
2744:	{
2745:		int ret = 0;
2746:	
2747:		if (!hdev->suspend_notifier.notifier_call &&
2748:		    !hci_test_quirk(hdev, HCI_QUIRK_NO_SUSPEND_NOTIFIER)) {
2749:			hdev->suspend_notifier.notifier_call = hci_suspend_notifier;
]

gemini-3.1-pro-preview

							input: 15012
							output: 37
							thoughts: 224
						

**Analyzing the Bluetooth HCI Device Release Path**

Okay, so I'm trying to figure out the exact sequence for releasing this Bluetooth HCI device. I see that `msft_release` is called within `hci_release_dev`. And `hci_release_dev`, I know, gets triggered when the device's reference count hits zero. But there's this weirdness: `hci_dev_close_sync` is also called from `hci_power_on`. That seems like a potential conflict, so I need to understand that better.

Let me go back and look at the call trace again to make sure I'm not missing anything:

```
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
```

Okay, confirmed. So, I need to check out what's happening within `hci_power_on` specifically. Let's dig into that `net/bluetooth/hci_core.c:937` and see what it's actually doing with `hci_dev_close_sync`. I'm guessing there's a specific condition or scenario where that's called during the power-on sequence that I need to understand.

map[File:net/bluetooth/hci_core.c FirstLine:910 LineCount:50]

map[Contents: 910:	
 911:		if (test_bit(HCI_UP, &hdev->flags) &&
 912:		    hci_dev_test_flag(hdev, HCI_MGMT) &&
 913:		    hci_dev_test_and_clear_flag(hdev, HCI_AUTO_OFF)) {
 914:			cancel_delayed_work(&hdev->power_off);
 915:			err = hci_powered_update_sync(hdev);
 916:			mgmt_power_on(hdev, err);
 917:			return;
 918:		}
 919:	
 920:		err = hci_dev_do_open(hdev);
 921:		if (err < 0) {
 922:			hci_dev_lock(hdev);
 923:			mgmt_set_powered_failed(hdev, err);
 924:			hci_dev_unlock(hdev);
 925:			return;
 926:		}
 927:	
 928:		/* During the HCI setup phase, a few error conditions are
 929:		 * ignored and they need to be checked now. If they are still
 930:		 * valid, it is important to turn the device back off.
 931:		 */
 932:		if (hci_dev_test_flag(hdev, HCI_RFKILLED) ||
 933:		    hci_dev_test_flag(hdev, HCI_UNCONFIGURED) ||
 934:		    (!bacmp(&hdev->bdaddr, BDADDR_ANY) &&
 935:		     !bacmp(&hdev->static_addr, BDADDR_ANY))) {
 936:			hci_dev_clear_flag(hdev, HCI_AUTO_OFF);
 937:			hci_dev_do_close(hdev);
 938:		} else if (hci_dev_test_flag(hdev, HCI_AUTO_OFF)) {
 939:			queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
 940:					   HCI_AUTO_OFF_TIMEOUT);
 941:		}
 942:	
 943:		if (hci_dev_test_and_clear_flag(hdev, HCI_SETUP)) {
 944:			/* For unconfigured devices, set the HCI_RAW flag
 945:			 * so that userspace can easily identify them.
 946:			 */
 947:			if (hci_dev_test_flag(hdev, HCI_UNCONFIGURED))
 948:				set_bit(HCI_RAW, &hdev->flags);
 949:	
 950:			/* For fully configured devices, this will send
 951:			 * the Index Added event. For unconfigured devices,
 952:			 * it will send Unconfigued Index Added event.
 953:			 *
 954:			 * Devices with HCI_QUIRK_RAW_DEVICE are ignored
 955:			 * and no event will be send.
 956:			 */
 957:			mgmt_index_added(hdev);
 958:		} else if (hci_dev_test_and_clear_flag(hdev, HCI_CONFIG)) {
 959:			/* When the controller is now configured, then it
]

gemini-3.1-pro-preview

							input: 16521
							output: 53
							thoughts: 67
						

Okay, here's my interpretation of those thoughts, presented as my own mental process:

**Diving into Bluetooth Device Power-On**

Right, so I'm looking at this `hci_power_on` function. Immediately, I see it's handling a device that's either not set up correctly or doesn't even have a valid address. In either of those cases, it jumps to `hci_dev_do_close(hdev)`. Okay, that makes sense - we need to clean things up if there's an issue during initialization.

Hold on a second... `hci_dev_do_close` then goes ahead and calls `hci_dev_close_sync`. I'm going to want to understand what's in that sequence. That seems pretty standard.

Now, my real question is - where does `msft_register` come into play in this entire flow? I need to understand how the Microsoft-specific registration is tied to the device power-on and close operations. I'm going to look at the surrounding calls to ensure I don't miss anything. I'll need to trace the call paths to be sure.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:0 Name:msft_register SourceTreePrefix:net/bluetooth/]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_register_dev SourceFile:net/bluetooth/hci_core.c SourceLine:2635]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 16960
							output: 38
							thoughts: 46
						

Okay, let's break this down.

**Diving into the Bluetooth HCI Device Registration**

Right, so `msft_register` is invoked within `hci_register_dev`. Interesting.  I need to understand what's happening in `hci_register_dev` since that's where the Microsoft-specific registration is occurring.  Time to pull up the source code, specifically `net/bluetooth/hci_core.c:2635`. I'm expecting to see the standard device registration flow, but with `msft_register` added in for Microsoft's proprietary handling, whatever that may be. I'm hoping it's well-integrated and doesn't introduce any obvious red flags in the base device initialization. Let's see what the function does and where that `msft_register` is called.

map[File:net/bluetooth/hci_core.c FirstLine:2610 LineCount:50]

map[Contents:2610:		list_add(&hdev->list, &hci_dev_list);
2611:		write_unlock(&hci_dev_list_lock);
2612:	
2613:		/* Devices that are marked for raw-only usage are unconfigured
2614:		 * and should not be included in normal operation.
2615:		 */
2616:		if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
2617:			hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
2618:	
2619:		/* Mark Remote Wakeup connection flag as supported if driver has wakeup
2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
2650:	/* Unregister HCI device */
2651:	void hci_unregister_dev(struct hci_dev *hdev)
2652:	{
2653:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2654:	
2655:		mutex_lock(&hdev->unregister_lock);
2656:		hci_dev_set_flag(hdev, HCI_UNREGISTER);
2657:		mutex_unlock(&hdev->unregister_lock);
2658:	
2659:		write_lock(&hci_dev_list_lock);
]

gemini-3.1-pro-preview

							input: 17997
							output: 36
							thoughts: 404
						

**My Concerns Regarding Concurrency in MSFT Extension Registration**

Okay, hold on a second! I just realized something critical about the execution order here. The `queue_work(hdev->req_workqueue, &hdev->power_on);` call happens *before* `msft_register(hdev);`. If that `power_on` work gets dispatched immediately, it'll trigger `hci_power_on`, which, in turn, calls `hci_dev_do_close` and then `msft_do_close`. Now, in `msft_do_close`, it checks `if (!msft)`, where `msft` is assigned `hdev->msft_data`.

Initially, that's safe because if `msft_register` hasn't run yet, `hdev->msft_data` is `NULL`, so `msft_do_close` just exits gracefully. But here's the kicker: what if `msft_register` and `msft_do_close` run concurrently?

Let me review the code for `msft_register` really quickly. Okay, I see it's allocating `msft` with `kzalloc_obj`, and then there are initializations for the lists: `INIT_LIST_HEAD(&msft->handle_map);` and `INIT_LIST_HEAD(&msft->address_filters);`. And then the crucial part: `hdev->msft_data = msft;` followed by `mutex_init(&msft->filter_lock);`.

The issue is this: if `hdev->msft_data = msft;` executes *before* `mutex_init(&msft->filter_lock);`, then `msft_do_close` might read `hdev->msft_data`, see that it's *not* NULL anymore, and try to lock the mutex *before* it's been initialized, by calling `mutex_lock(&msft->filter_lock)`.

I need to make sure that order of execution is consistent. I need to make sure `hdev->msft_data = msft;` is performed only *after* the MSFT structure is fully initialized, including the mutex.

Hang on... isn't `mutex_init` a macro? I should check what that expands to. Let me refresh my memory of that...

map[File:net/bluetooth/msft.c FirstLine:750 LineCount:25]

map[Contents: 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
]

gemini-3.1-pro-preview

							input: 19303
							output: 26
							thoughts: 440
						

**The "Aha!" Moment and Debugging Deep Dive**

Yes! I think I've got it. That code snippet...

```c
hdev->msft_data = msft;
mutex_init(&msft->filter_lock);
```

...that sequence is problematic. If `hdev->msft_data` gets assigned *before* `mutex_init` is called, another thread could read that pointer and try to grab the lock *before* it's initialized. But wait...`kzalloc_obj` zero's the memory. Okay, so `msft->filter_lock` is just zeroes initially. If I call `mutex_lock` on that, `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` should trigger because `magic` is `0`, not the address of the lock. Brilliant! That perfectly explains the crash I've been seeing.

Alright, let's confirm if `msft_do_close` could be called from a `power_on` work.

Looking at `hci_register_dev`, I see:

```c
queue_work(hdev->req_workqueue, &hdev->power_on);

idr_init(&hdev->adv_monitors_idr);
msft_register(hdev);
```

The `power_on` work is queued on `hdev->req_workqueue`. The associated function is `hci_power_on`. So, is it possible for that to lead to the bad code path? `hci_power_on` might call `hci_dev_do_close(hdev)` if `hci_dev_test_flag(hdev, HCI_UNCONFIGURED)` is true. Let's dig deeper, is `HCI_UNCONFIGURED` set? In `hci_register_dev` there is this code:

```c
if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
		hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
```
Or maybe somewhere else. But wait a moment, this syzkaller program uses `vhci` (Virtual HCI)! Time to focus on the `vhci` driver.

map[Expression:vhci PathPrefix:drivers/bluetooth/]

map[Output:drivers/bluetooth/Kconfig=340=config BT_HCIVHCI
--
drivers/bluetooth/Kconfig-347-	  Say Y here to compile support for virtual HCI devices into the
drivers/bluetooth/Kconfig:348:	  kernel or say M to compile it as module (hci_vhci).
drivers/bluetooth/Kconfig-349-
--
drivers/bluetooth/Makefile-5-
drivers/bluetooth/Makefile:6:obj-$(CONFIG_BT_HCIVHCI)	+= hci_vhci.o
drivers/bluetooth/Makefile-7-obj-$(CONFIG_BT_HCIUART)	+= hci_uart.o
--
drivers/bluetooth/hci_vhci.c=32=static bool amp;
drivers/bluetooth/hci_vhci.c-33-
drivers/bluetooth/hci_vhci.c:34:struct vhci_data {
drivers/bluetooth/hci_vhci.c-35-	struct hci_dev *hdev;
--
drivers/bluetooth/hci_vhci.c-50-
drivers/bluetooth/hci_vhci.c:51:static int vhci_open_dev(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-52-{
--
drivers/bluetooth/hci_vhci.c-55-
drivers/bluetooth/hci_vhci.c:56:static int vhci_close_dev(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-57-{
drivers/bluetooth/hci_vhci.c:58:	struct vhci_data *data = hci_get_drvdata(hdev);
drivers/bluetooth/hci_vhci.c-59-
--
drivers/bluetooth/hci_vhci.c-64-
drivers/bluetooth/hci_vhci.c:65:static int vhci_flush(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-66-{
drivers/bluetooth/hci_vhci.c:67:	struct vhci_data *data = hci_get_drvdata(hdev);
drivers/bluetooth/hci_vhci.c-68-
--
drivers/bluetooth/hci_vhci.c-73-
drivers/bluetooth/hci_vhci.c:74:static int vhci_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
drivers/bluetooth/hci_vhci.c-75-{
drivers/bluetooth/hci_vhci.c:76:	struct vhci_data *data = hci_get_drvdata(hdev);
drivers/bluetooth/hci_vhci.c-77-
--
drivers/bluetooth/hci_vhci.c-86-
drivers/bluetooth/hci_vhci.c:87:static int vhci_get_data_path_id(struct hci_dev *hdev, u8 *data_path_id)
drivers/bluetooth/hci_vhci.c-88-{
--
drivers/bluetooth/hci_vhci.c-92-
drivers/bluetooth/hci_vhci.c:93:static int vhci_get_codec_config_data(struct hci_dev *hdev, __u8 type,
drivers/bluetooth/hci_vhci.c-94-				      struct bt_codec *codec, __u8 *vnd_len,
--
drivers/bluetooth/hci_vhci.c-104-
drivers/bluetooth/hci_vhci.c:105:static bool vhci_wakeup(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-106-{
drivers/bluetooth/hci_vhci.c:107:	struct vhci_data *data = hci_get_drvdata(hdev);
drivers/bluetooth/hci_vhci.c-108-
--
drivers/bluetooth/hci_vhci.c=112=static ssize_t force_suspend_read(struct file *file, char __user *user_buf,
--
drivers/bluetooth/hci_vhci.c-114-{
drivers/bluetooth/hci_vhci.c:115:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-116-	char buf[3];
--
drivers/bluetooth/hci_vhci.c-123-
drivers/bluetooth/hci_vhci.c:124:static void vhci_suspend_work(struct work_struct *work)
drivers/bluetooth/hci_vhci.c-125-{
drivers/bluetooth/hci_vhci.c:126:	struct vhci_data *data = container_of(work, struct vhci_data,
drivers/bluetooth/hci_vhci.c-127-					      suspend_work);
--
drivers/bluetooth/hci_vhci.c=135=static ssize_t force_suspend_write(struct file *file,
--
drivers/bluetooth/hci_vhci.c-138-{
drivers/bluetooth/hci_vhci.c:139:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-140-	bool enable;
--
drivers/bluetooth/hci_vhci.c=164=static ssize_t force_wakeup_read(struct file *file, char __user *user_buf,
--
drivers/bluetooth/hci_vhci.c-166-{
drivers/bluetooth/hci_vhci.c:167:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-168-	char buf[3];
--
drivers/bluetooth/hci_vhci.c=176=static ssize_t force_wakeup_write(struct file *file,
--
drivers/bluetooth/hci_vhci.c-179-{
drivers/bluetooth/hci_vhci.c:180:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-181-	bool enable;
--
drivers/bluetooth/hci_vhci.c=203=static int msft_opcode_set(void *data, u64 val)
drivers/bluetooth/hci_vhci.c-204-{
drivers/bluetooth/hci_vhci.c:205:	struct vhci_data *vhci = data;
drivers/bluetooth/hci_vhci.c-206-
--
drivers/bluetooth/hci_vhci.c-209-
drivers/bluetooth/hci_vhci.c:210:	if (vhci->msft_opcode)
drivers/bluetooth/hci_vhci.c-211-		return -EALREADY;
drivers/bluetooth/hci_vhci.c-212-
drivers/bluetooth/hci_vhci.c:213:	vhci->msft_opcode = val;
drivers/bluetooth/hci_vhci.c-214-
--
drivers/bluetooth/hci_vhci.c=218=static int msft_opcode_get(void *data, u64 *val)
drivers/bluetooth/hci_vhci.c-219-{
drivers/bluetooth/hci_vhci.c:220:	struct vhci_data *vhci = data;
drivers/bluetooth/hci_vhci.c-221-
drivers/bluetooth/hci_vhci.c:222:	*val = vhci->msft_opcode;
drivers/bluetooth/hci_vhci.c-223-
--
drivers/bluetooth/hci_vhci.c=230=static ssize_t aosp_capable_read(struct file *file, char __user *user_buf,
--
drivers/bluetooth/hci_vhci.c-232-{
drivers/bluetooth/hci_vhci.c:233:	struct vhci_data *vhci = file->private_data;
drivers/bluetooth/hci_vhci.c-234-	char buf[3];
drivers/bluetooth/hci_vhci.c-235-
drivers/bluetooth/hci_vhci.c:236:	buf[0] = vhci->aosp_capable ? 'Y' : 'N';
drivers/bluetooth/hci_vhci.c-237-	buf[1] = '\n';
--
drivers/bluetooth/hci_vhci.c=242=static ssize_t aosp_capable_write(struct file *file,
--
drivers/bluetooth/hci_vhci.c-245-{
drivers/bluetooth/hci_vhci.c:246:	struct vhci_data *vhci = file->private_data;
drivers/bluetooth/hci_vhci.c-247-	bool enable;
--
drivers/bluetooth/hci_vhci.c-256-
drivers/bluetooth/hci_vhci.c:257:	if (vhci->aosp_capable)
drivers/bluetooth/hci_vhci.c-258-		return -EALREADY;
drivers/bluetooth/hci_vhci.c-259-
drivers/bluetooth/hci_vhci.c:260:	vhci->aosp_capable = enable;
drivers/bluetooth/hci_vhci.c-261-
--
drivers/bluetooth/hci_vhci.c=265=static const struct file_operations aosp_capable_fops = {
--
drivers/bluetooth/hci_vhci.c-271-
drivers/bluetooth/hci_vhci.c:272:static int vhci_setup(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-273-{
drivers/bluetooth/hci_vhci.c:274:	struct vhci_data *vhci = hci_get_drvdata(hdev);
drivers/bluetooth/hci_vhci.c-275-
drivers/bluetooth/hci_vhci.c:276:	if (vhci->msft_opcode)
drivers/bluetooth/hci_vhci.c:277:		hci_set_msft_opcode(hdev, vhci->msft_opcode);
drivers/bluetooth/hci_vhci.c-278-
drivers/bluetooth/hci_vhci.c:279:	if (vhci->aosp_capable)
drivers/bluetooth/hci_vhci.c-280-		hci_set_aosp_capable(hdev);
--
drivers/bluetooth/hci_vhci.c-284-
drivers/bluetooth/hci_vhci.c:285:static void vhci_coredump(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-286-{
--
drivers/bluetooth/hci_vhci.c-289-
drivers/bluetooth/hci_vhci.c:290:static void vhci_coredump_hdr(struct hci_dev *hdev, struct sk_buff *skb)
drivers/bluetooth/hci_vhci.c-291-{
--
drivers/bluetooth/hci_vhci.c-293-
drivers/bluetooth/hci_vhci.c:294:	buf = "Controller Name: vhci_ctrl\n";
drivers/bluetooth/hci_vhci.c-295-	skb_put_data(skb, buf, strlen(buf));
drivers/bluetooth/hci_vhci.c-296-
drivers/bluetooth/hci_vhci.c:297:	buf = "Firmware Version: vhci_fw\n";
drivers/bluetooth/hci_vhci.c-298-	skb_put_data(skb, buf, strlen(buf));
drivers/bluetooth/hci_vhci.c-299-
drivers/bluetooth/hci_vhci.c:300:	buf = "Driver: vhci_drv\n";
drivers/bluetooth/hci_vhci.c-301-	skb_put_data(skb, buf, strlen(buf));
drivers/bluetooth/hci_vhci.c-302-
drivers/bluetooth/hci_vhci.c:303:	buf = "Vendor: vhci\n";
drivers/bluetooth/hci_vhci.c-304-	skb_put_data(skb, buf, strlen(buf));
--
drivers/bluetooth/hci_vhci.c=323=static ssize_t force_devcd_write(struct file *file, const char __user *user_buf,
--
drivers/bluetooth/hci_vhci.c-325-{
drivers/bluetooth/hci_vhci.c:326:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-327-	struct hci_dev *hdev = data->hdev;
--
drivers/bluetooth/hci_vhci.c-355-
drivers/bluetooth/hci_vhci.c:356:	hci_devcd_register(hdev, vhci_coredump, vhci_coredump_hdr, NULL);
drivers/bluetooth/hci_vhci.c-357-
--
drivers/bluetooth/hci_vhci.c=388=static const struct file_operations force_devcoredump_fops = {
--
drivers/bluetooth/hci_vhci.c-392-
drivers/bluetooth/hci_vhci.c:393:static void vhci_debugfs_init(struct vhci_data *data)
drivers/bluetooth/hci_vhci.c-394-{
--
drivers/bluetooth/hci_vhci.c-414-
drivers/bluetooth/hci_vhci.c:415:static int __vhci_create_device(struct vhci_data *data, __u8 opcode)
drivers/bluetooth/hci_vhci.c-416-{
--
drivers/bluetooth/hci_vhci.c-441-
drivers/bluetooth/hci_vhci.c:442:	hdev->open  = vhci_open_dev;
drivers/bluetooth/hci_vhci.c:443:	hdev->close = vhci_close_dev;
drivers/bluetooth/hci_vhci.c:444:	hdev->flush = vhci_flush;
drivers/bluetooth/hci_vhci.c:445:	hdev->send  = vhci_send_frame;
drivers/bluetooth/hci_vhci.c:446:	hdev->get_data_path_id = vhci_get_data_path_id;
drivers/bluetooth/hci_vhci.c:447:	hdev->get_codec_config_data = vhci_get_codec_config_data;
drivers/bluetooth/hci_vhci.c:448:	hdev->wakeup = vhci_wakeup;
drivers/bluetooth/hci_vhci.c:449:	hdev->setup = vhci_setup;
drivers/bluetooth/hci_vhci.c-450-	hci_set_quirk(hdev, HCI_QUIRK_NON_PERSISTENT_SETUP);
--
drivers/bluetooth/hci_vhci.c-469-	if (!IS_ERR_OR_NULL(hdev->debugfs))
drivers/bluetooth/hci_vhci.c:470:		vhci_debugfs_init(data);
drivers/bluetooth/hci_vhci.c-471-
--
drivers/bluetooth/hci_vhci.c-483-
drivers/bluetooth/hci_vhci.c:484:static int vhci_create_device(struct vhci_data *data, __u8 opcode)
drivers/bluetooth/hci_vhci.c-485-{
--
drivers/bluetooth/hci_vhci.c-488-	mutex_lock(&data->open_mutex);
drivers/bluetooth/hci_vhci.c:489:	err = __vhci_create_device(data, opcode);
drivers/bluetooth/hci_vhci.c-490-	mutex_unlock(&data->open_mutex);
--
drivers/bluetooth/hci_vhci.c-494-
drivers/bluetooth/hci_vhci.c:495:static inline ssize_t vhci_get_user(struct vhci_data *data,
drivers/bluetooth/hci_vhci.c-496-				    struct iov_iter *from)
--
drivers/bluetooth/hci_vhci.c-545-
drivers/bluetooth/hci_vhci.c:546:		ret = vhci_create_device(data, opcode);
drivers/bluetooth/hci_vhci.c-547-		break;
--
drivers/bluetooth/hci_vhci.c-556-
drivers/bluetooth/hci_vhci.c:557:static inline ssize_t vhci_put_user(struct vhci_data *data,
drivers/bluetooth/hci_vhci.c-558-				    struct sk_buff *skb,
--
drivers/bluetooth/hci_vhci.c-588-
drivers/bluetooth/hci_vhci.c:589:static ssize_t vhci_read(struct file *file,
drivers/bluetooth/hci_vhci.c-590-			 char __user *buf, size_t count, loff_t *pos)
drivers/bluetooth/hci_vhci.c-591-{
drivers/bluetooth/hci_vhci.c:592:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-593-	struct sk_buff *skb;
--
drivers/bluetooth/hci_vhci.c-598-		if (skb) {
drivers/bluetooth/hci_vhci.c:599:			ret = vhci_put_user(data, skb, buf, count);
drivers/bluetooth/hci_vhci.c-600-			if (ret < 0)
--
drivers/bluetooth/hci_vhci.c-620-
drivers/bluetooth/hci_vhci.c:621:static ssize_t vhci_write(struct kiocb *iocb, struct iov_iter *from)
drivers/bluetooth/hci_vhci.c-622-{
drivers/bluetooth/hci_vhci.c-623-	struct file *file = iocb->ki_filp;
drivers/bluetooth/hci_vhci.c:624:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-625-
drivers/bluetooth/hci_vhci.c:626:	return vhci_get_user(data, from);
drivers/bluetooth/hci_vhci.c-627-}
drivers/bluetooth/hci_vhci.c-628-
drivers/bluetooth/hci_vhci.c:629:static __poll_t vhci_poll(struct file *file, poll_table *wait)
drivers/bluetooth/hci_vhci.c-630-{
drivers/bluetooth/hci_vhci.c:631:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-632-
--
drivers/bluetooth/hci_vhci.c-640-
drivers/bluetooth/hci_vhci.c:641:static void vhci_open_timeout(struct work_struct *work)
drivers/bluetooth/hci_vhci.c-642-{
drivers/bluetooth/hci_vhci.c:643:	struct vhci_data *data = container_of(work, struct vhci_data,
drivers/bluetooth/hci_vhci.c-644-					      open_timeout.work);
drivers/bluetooth/hci_vhci.c-645-
drivers/bluetooth/hci_vhci.c:646:	vhci_create_device(data, 0x00);
drivers/bluetooth/hci_vhci.c-647-}
drivers/bluetooth/hci_vhci.c-648-
drivers/bluetooth/hci_vhci.c:649:static int vhci_open(struct inode *inode, struct file *file)
drivers/bluetooth/hci_vhci.c-650-{
drivers/bluetooth/hci_vhci.c:651:	struct vhci_data *data;
drivers/bluetooth/hci_vhci.c-652-
--
drivers/bluetooth/hci_vhci.c-660-	mutex_init(&data->open_mutex);
drivers/bluetooth/hci_vhci.c:661:	INIT_DELAYED_WORK(&data->open_timeout, vhci_open_timeout);
drivers/bluetooth/hci_vhci.c:662:	INIT_WORK(&data->suspend_work, vhci_suspend_work);
drivers/bluetooth/hci_vhci.c-663-
--
drivers/bluetooth/hci_vhci.c-671-
drivers/bluetooth/hci_vhci.c:672:static void vhci_debugfs_remove(struct hci_dev *hdev)
drivers/bluetooth/hci_vhci.c-673-{
--
drivers/bluetooth/hci_vhci.c-686-
drivers/bluetooth/hci_vhci.c:687:static int vhci_release(struct inode *inode, struct file *file)
drivers/bluetooth/hci_vhci.c-688-{
drivers/bluetooth/hci_vhci.c:689:	struct vhci_data *data = file->private_data;
drivers/bluetooth/hci_vhci.c-690-	struct hci_dev *hdev;
--
drivers/bluetooth/hci_vhci.c-698-		if (!IS_ERR_OR_NULL(hdev->debugfs))
drivers/bluetooth/hci_vhci.c:699:			vhci_debugfs_remove(hdev);
drivers/bluetooth/hci_vhci.c-700-		hci_unregister_dev(hdev);
--
drivers/bluetooth/hci_vhci.c-710-
drivers/bluetooth/hci_vhci.c:711:static const struct file_operations vhci_fops = {
drivers/bluetooth/hci_vhci.c-712-	.owner		= THIS_MODULE,
drivers/bluetooth/hci_vhci.c:713:	.read		= vhci_read,
drivers/bluetooth/hci_vhci.c:714:	.write_iter	= vhci_write,
drivers/bluetooth/hci_vhci.c:715:	.poll		= vhci_poll,
drivers/bluetooth/hci_vhci.c:716:	.open		= vhci_open,
drivers/bluetooth/hci_vhci.c:717:	.release	= vhci_release,
drivers/bluetooth/hci_vhci.c-718-};
drivers/bluetooth/hci_vhci.c-719-
drivers/bluetooth/hci_vhci.c:720:static struct miscdevice vhci_miscdev = {
drivers/bluetooth/hci_vhci.c:721:	.name	= "vhci",
drivers/bluetooth/hci_vhci.c:722:	.fops	= &vhci_fops,
drivers/bluetooth/hci_vhci.c-723-	.minor	= VHCI_MINOR,
drivers/bluetooth/hci_vhci.c-724-};
drivers/bluetooth/hci_vhci.c:725:module_misc_device(vhci_miscdev);
drivers/bluetooth/hci_vhci.c-726-
--
drivers/bluetooth/hci_vhci.c=733=MODULE_LICENSE("GPL");
drivers/bluetooth/hci_vhci.c:734:MODULE_ALIAS("devname:vhci");
drivers/bluetooth/hci_vhci.c-735-MODULE_ALIAS_MISCDEV(VHCI_MINOR);
]

gemini-3.1-pro-preview

							input: 26165
							output: 38
							thoughts: 697
						

**Analyzing a Syzkaller-Generated Test Case**

Okay, so I'm looking at this syzkaller-generated program, and my initial thought is: interesting. It looks like it's trying to interact with the virtual HCI device, `/dev/vhci`. Let's break this down. The program first copies the device path into memory, then opens the device using `openat`. The interesting part is that the file descriptor `0xffffff9c` which is effectively -100, is used which usually represent a file system internal file descriptor that is assigned for system internal use. Then, it attempts to configure the filesystem using `fsconfig`. After that, it does a `read` from the opened file descriptor and stores the result as a new file descriptor. Now, here's where it gets intriguing: there's a `write` call to `/dev/vhci`.

This `write` operation is the key. The write operation to vhci will call the `vhci_write` function. This is where the magic (or the bug, potentially) lies. The program then prepares a write operation. I can tell from previous experience that in the context of `vhci`, the `write` call is going to trigger something in the kernel. `vhci_write` calls `vhci_get_user`, which suggests that the input from user space is being processed. I want to see what opcode `0xff` is used for. This specific value will dictate the behavior, and how the device will be programmed.

My next step is to head over to the source code for the vhci driver, specifically, `drivers/bluetooth/hci_vhci.c`. I will be looking into the `__vhci_create_device` function, to see how the device is created. I need to understand what this opcode means and how the device interacts with it in the write operation, so I have to understand the whole process of vhci initialization. This could be where the vulnerability lies if it tries to dereference a user controlled value without any boundaries.

map[File:drivers/bluetooth/hci_vhci.c FirstLine:410 LineCount:50]

map[Contents: 410:	
 411:		debugfs_create_file("force_devcoredump", 0644, hdev->debugfs, data,
 412:				    &force_devcoredump_fops);
 413:	}
 414:	
 415:	static int __vhci_create_device(struct vhci_data *data, __u8 opcode)
 416:	{
 417:		struct hci_dev *hdev;
 418:		struct sk_buff *skb;
 419:	
 420:		if (data->hdev)
 421:			return -EBADFD;
 422:	
 423:		/* bits 2-5 are reserved (must be zero) */
 424:		if (opcode & 0x3c)
 425:			return -EINVAL;
 426:	
 427:		skb = bt_skb_alloc(4, GFP_KERNEL);
 428:		if (!skb)
 429:			return -ENOMEM;
 430:	
 431:		hdev = hci_alloc_dev();
 432:		if (!hdev) {
 433:			kfree_skb(skb);
 434:			return -ENOMEM;
 435:		}
 436:	
 437:		data->hdev = hdev;
 438:	
 439:		hdev->bus = HCI_VIRTUAL;
 440:		hci_set_drvdata(hdev, data);
 441:	
 442:		hdev->open  = vhci_open_dev;
 443:		hdev->close = vhci_close_dev;
 444:		hdev->flush = vhci_flush;
 445:		hdev->send  = vhci_send_frame;
 446:		hdev->get_data_path_id = vhci_get_data_path_id;
 447:		hdev->get_codec_config_data = vhci_get_codec_config_data;
 448:		hdev->wakeup = vhci_wakeup;
 449:		hdev->setup = vhci_setup;
 450:		hci_set_quirk(hdev, HCI_QUIRK_NON_PERSISTENT_SETUP);
 451:		hci_set_quirk(hdev, HCI_QUIRK_SYNC_FLOWCTL_SUPPORTED);
 452:	
 453:		/* bit 6 is for external configuration */
 454:		if (opcode & 0x40)
 455:			hci_set_quirk(hdev, HCI_QUIRK_EXTERNAL_CONFIG);
 456:	
 457:		/* bit 7 is for raw device */
 458:		if (opcode & 0x80)
 459:			hci_set_quirk(hdev, HCI_QUIRK_RAW_DEVICE);
]

gemini-3.1-pro-preview

							input: 28145
							output: 38
							thoughts: 101
						

**Analyzing the Syzkaller Output**

Okay, so the syzkaller program is writing `\xff\x80`. Right, let's break this down. First thought: `\xff` is almost certainly the opcode. Now, I need to check the logic around that. Let's see... `0xff & 0x3c`... that evaluates to `0x3c`, which is not zero, so it returns `-EINVAL`. Makes sense. Hang on, just to be absolutely clear, let me reiterate: `\xff` represents 255. And the syzkaller program *again* writes `\xff\x80`. Time to double-check my assumptions. I think it's time to dig into `vhci_get_user` and understand why this sequence is triggering this particular error path.

map[File:drivers/bluetooth/hci_vhci.c FirstLine:490 LineCount:50]

map[Contents: 490:		mutex_unlock(&data->open_mutex);
 491:	
 492:		return err;
 493:	}
 494:	
 495:	static inline ssize_t vhci_get_user(struct vhci_data *data,
 496:					    struct iov_iter *from)
 497:	{
 498:		size_t len = iov_iter_count(from);
 499:		struct sk_buff *skb;
 500:		__u8 pkt_type, opcode;
 501:		int ret;
 502:	
 503:		if (len < 2 || len > HCI_MAX_FRAME_SIZE)
 504:			return -EINVAL;
 505:	
 506:		skb = bt_skb_alloc(len, GFP_KERNEL);
 507:		if (!skb)
 508:			return -ENOMEM;
 509:	
 510:		if (!copy_from_iter_full(skb_put(skb, len), len, from)) {
 511:			kfree_skb(skb);
 512:			return -EFAULT;
 513:		}
 514:	
 515:		pkt_type = *((__u8 *) skb->data);
 516:		skb_pull(skb, 1);
 517:	
 518:		switch (pkt_type) {
 519:		case HCI_EVENT_PKT:
 520:		case HCI_ACLDATA_PKT:
 521:		case HCI_SCODATA_PKT:
 522:		case HCI_ISODATA_PKT:
 523:			if (!data->hdev) {
 524:				kfree_skb(skb);
 525:				return -ENODEV;
 526:			}
 527:	
 528:			hci_skb_pkt_type(skb) = pkt_type;
 529:	
 530:			ret = hci_recv_frame(data->hdev, skb);
 531:			break;
 532:	
 533:		case HCI_VENDOR_PKT:
 534:			cancel_delayed_work_sync(&data->open_timeout);
 535:	
 536:			opcode = *((__u8 *) skb->data);
 537:			skb_pull(skb, 1);
 538:	
 539:			if (skb->len > 0) {
]

gemini-3.1-pro-preview

							input: 29177
							output: 38
							thoughts: 762
						

**My Analysis of a Potential Data Race in Bluetooth Driver Initialization**

Okay, let's break this down. I'm looking at this incoming packet, `pkt_type` is `\xff` – that's HCI Vendor Packet. The `opcode` is `\x80`. Cool, now let's see, `0x80 & 0x3c` is zero, so that checks out. The `opcode & 0x80` is true, so that means we're setting `HCI_QUIRK_RAW_DEVICE`. Then `hci_register_dev(hdev)` is called. Inside `hci_register_dev`, there's a check for `HCI_QUIRK_RAW_DEVICE`, and if it's set, then `HCI_UNCONFIGURED` is set too.

Alright, so far, so good. Then `queue_work(hdev->req_workqueue, &hdev->power_on);` gets called. And after that, `msft_register(hdev)` gets called. This is where things get interesting.

If the `power_on` work runs quickly (maybe on another CPU), it calls `hci_power_on`. Because `HCI_UNCONFIGURED` is set, `hci_power_on` will call `hci_dev_do_close(hdev)`. And that calls `hci_dev_close_sync(hdev)` which in turn calls `msft_do_close(hdev)`.

Inside `msft_do_close`, we see this critical section: there's a quick check and then: `mutex_lock(&msft->filter_lock);`

Now, let's look at `msft_register(hdev)`.  Here, `msft` gets allocated with `kzalloc_obj`, then the list heads get initialized, then, crucially, `hdev->msft_data = msft;` is assigned. *And then* a mutex is initialized `mutex_init(&msft->filter_lock);`.

The problem is clear to me. If `hdev->msft_data = msft;` gets executed *before* `mutex_init(&msft->filter_lock)`, and `msft_do_close` runs concurrently and reads `hdev->msft_data`, it might find a valid pointer to the `msft` structure, and it will try to lock the `filter_lock` *before* the mutex is initialized. That uninitialized mutex means it's full of zeros. So, `mutex_lock` on this uninitialized value will trigger that familiar warning: `DEBUG_LOCKS_WARN_ON(lock->magic != lock)`. That's a classic data race, a definite initialization order bug.

My immediate instinct is the fix is to move the initialization of the mutex BEFORE assigning `hdev->msft_data = msft;`, right? But wait a minute. Is that enough? We have a new problem, even if we initialize the mutex *before* assigning the data pointer, other things might still be running concurrently like `INIT_LIST_HEAD` or other member initializations. Thinking about it, the real fix is to make sure `msft_register` is executed BEFORE `queue_work(hdev->req_workqueue, &hdev->power_on);`. Let me check that `hci_register_dev` again... yes, that's definitely the root cause. This order needs to be fixed.

map[File:net/bluetooth/hci_core.c FirstLine:2620 LineCount:30]

map[Contents:2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
]

gemini-3.1-pro-preview

							input: 31172
							output: 36
							thoughts: 263
						

**My Analysis of the Initialization Sequence**

Okay, so I'm looking at this initialization code and thinking through the execution flow. I see that `queue_work(hdev->req_workqueue, &hdev->power_on);` is called *before* both `idr_init(&hdev->adv_monitors_idr);` and `msft_register(hdev);`. The potential issue here is that if `power_on` starts running *before* those are finished, it could call functions that rely on uninitialized parts.

Specifically, `power_on` could call `hci_dev_do_close`, and that in turn, could call `hci_adv_monitors_clear(hdev)` or `msft_do_close(hdev)`.  Hmm, I know `hci_dev_close_sync` *doesn't* call `hci_adv_monitors_clear`, but it *does* call `msft_do_close(hdev)`.

The crucial thing is, if I move the `msft_register` call *before* `queue_work`, then `msft` will be fully initialized before any work is queued to run, ensuring it's ready for any potential calls.

Let's check for dependencies, though. `msft_register` seems to be just allocating memory, and initializing some lists and mutexes. Similarly, `idr_init` is just initializing that IDR. Based on this, it *appears* completely safe and correct to move those calls before `queue_work`. I need to be 100% sure before I make the change, though. So let me verify everything `msft_register` does and confirm there are no more dependencies!

map[File:net/bluetooth/msft.c FirstLine:753 LineCount:20]

map[Contents: 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
]

gemini-3.1-pro-preview

							input: 32144
							output: 39
							thoughts: 78
						

**My Initial Assessment**

Okay, so `msft_register` is purely an allocation and initialization function, got it. Similarly, `idr_init(&hdev->adv_monitors_idr)` is just initializing, nothing more. I find myself wondering about the placement of these calls. Why are they positioned after `queue_work`? It strikes me as potentially an oversight, a subtle error that might be worth investigating. My next step is clear: I'll dive into the `git blame` history of `hci_register_dev`. That should shed some light on the order of additions and potentially reveal the reasoning, or lack thereof, behind the current sequence. This could uncover a latent bug or just reinforce that it's a non-issue.

map[End:2638 File:net/bluetooth/hci_core.c Start:2628]

map[Output:9111786492f13 2628) 	error = hci_register_suspend_notifier(hdev);
9111786492f13 2629) 	if (error)
0d75da38e060d 2630) 		BT_WARN("register suspend notifier failed error:%d\n", error);
9952d90ea2885 2631) 
1920257316615 2632) 	queue_work(hdev->req_workqueue, &hdev->power_on);
fbe96d6ff9f4e 2633) 
e5e1e7fd470cc 2634) 	idr_init(&hdev->adv_monitors_idr);
5031ffcc79b81 2635) 	msft_register(hdev);
e5e1e7fd470cc 2636) 
^1da177e4c3f4 2637) 	return id;
f48fd9c8cd746 2638) 
]

gemini-3.1-pro-preview

							input: 32741
							output: 26
							thoughts: 79
						

Okay, let me break this down.

**Analyzing Recent Driver Initialization Changes**

Alright, so I see these two commits in the driver code, and my initial thought is to understand the implications of the changes. The first commit, `5031ffcc79b81`, added `msft_register(hdev);`. Given my understanding of the Microsoft driver framework, this is likely registering the hardware device (`hdev`) with the system. It's the standard initialization and registration process. Nothing unexpected there, but I need to understand what else relies on this now.

Then, there's `e5e1e7fd470cc`, which introduces `idr_init(&hdev->adv_monitors_idr);`. The `idr_init` function calls suggest an IDR (Integer ID Register) structure. This is immediately interesting. This means that now my device, `hdev`, is using an IDR. This suggests that the driver is now managing a set of dynamically allocated integer IDs. This tells me that the driver now requires a means to track and manage some form of "advanced monitors", and the IDR is a resource management solution. This is definitely worth a closer look.

I'll start with that first commit, `5031ffcc79b81`, because that seems like the fundamental change I should start with. Let me examine the context surrounding that `msft_register` call. I need to figure out what context this function runs in and what other modules might now depend on this registration. I also need to understand any side effects of the `idr_init` change in the subsequent commit.

map[Commit:5031ffcc79b81]

map[Output:commit 5031ffcc79b81776ac8f7f8b1a585aed8818e3d1
Author: Miao-chen Chou <mcchou@chromium.org>
Date:   Thu Sep 9 14:10:23 2021 -0700

    Bluetooth: Keep MSFT ext info throughout a hci_dev's life cycle
    
    This splits the msft_do_{open/close} to msft_do_{open/close} and
    msft_{register/unregister}. With this change it is possible to retain
    the MSFT extension info irrespective of controller power on/off state.
    This helps bluetoothd to report correct 'supported features' of the
    controller to the D-Bus clients event if the controller is off. It also
    re-reads the MSFT info upon every msft_do_open().
    
    The following test steps were performed.
    1. Boot the test device and verify the MSFT support debug log in syslog.
    2. Power off the controller and read the 'supported features', power on
       and read again.
    3. Restart the bluetoothd and verify the 'supported features' value.
    
    Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Reviewed-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Alain Michaud <alainm@chromium.org>
    Signed-off-by: Manish Mandlik <mmandlik@google.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5236faa397fa..beda5dac1658 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3990,6 +3990,7 @@ int hci_register_dev(struct hci_dev *hdev)
 	queue_work(hdev->req_workqueue, &hdev->power_on);
 
 	idr_init(&hdev->adv_monitors_idr);
+	msft_register(hdev);
 
 	return id;
 
@@ -4022,6 +4023,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
 		cancel_work_sync(&hdev->suspend_prepare);
 	}
 
+	msft_unregister(hdev);
+
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index b4bfae41e8a5..21b1787e7893 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -184,28 +184,36 @@ static void reregister_monitor_on_restart(struct hci_dev *hdev, int handle)
 
 void msft_do_open(struct hci_dev *hdev)
 {
-	struct msft_data *msft;
+	struct msft_data *msft = hdev->msft_data;
 
 	if (hdev->msft_opcode == HCI_OP_NOP)
 		return;
 
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT extension not registered");
+		return;
+	}
+
 	bt_dev_dbg(hdev, "Initialize MSFT extension");
 
-	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
-	if (!msft)
-		return;
+	/* Reset existing MSFT data before re-reading */
+	kfree(msft->evt_prefix);
+	msft->evt_prefix = NULL;
+	msft->evt_prefix_len = 0;
+	msft->features = 0;
 
 	if (!read_supported_features(hdev, msft)) {
+		hdev->msft_data = NULL;
 		kfree(msft);
 		return;
 	}
 
-	INIT_LIST_HEAD(&msft->handle_map);
-	hdev->msft_data = msft;
-
 	if (msft_monitor_supported(hdev)) {
 		msft->reregistering = true;
 		msft_set_filter_enable(hdev, true);
+		/* Monitors get removed on power off, so we need to explicitly
+		 * tell the controller to re-monitor.
+		 */
 		reregister_monitor_on_restart(hdev, 0);
 	}
 }
@@ -221,8 +229,9 @@ void msft_do_close(struct hci_dev *hdev)
 
 	bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 
-	hdev->msft_data = NULL;
-
+	/* The controller will silently remove all monitors on power off.
+	 * Therefore, remove handle_data mapping and reset monitor state.
+	 */
 	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 		monitor = idr_find(&hdev->adv_monitors_idr,
 				   handle_data->mgmt_handle);
@@ -233,6 +242,34 @@ void msft_do_close(struct hci_dev *hdev)
 		list_del(&handle_data->list);
 		kfree(handle_data);
 	}
+}
+
+void msft_register(struct hci_dev *hdev)
+{
+	struct msft_data *msft = NULL;
+
+	bt_dev_dbg(hdev, "Register MSFT extension");
+
+	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
+	if (!msft) {
+		bt_dev_err(hdev, "Failed to register MSFT extension");
+		return;
+	}
+
+	INIT_LIST_HEAD(&msft->handle_map);
+	hdev->msft_data = msft;
+}
+
+void msft_unregister(struct hci_dev *hdev)
+{
+	struct msft_data *msft = hdev->msft_data;
+
+	if (!msft)
+		return;
+
+	bt_dev_dbg(hdev, "Unregister MSFT extension");
+
+	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
 	kfree(msft);
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 6e56d94b88d8..8018948c5975 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -13,6 +13,8 @@
 #if IS_ENABLED(CONFIG_BT_MSFTEXT)
 
 bool msft_monitor_supported(struct hci_dev *hdev);
+void msft_register(struct hci_dev *hdev);
+void msft_unregister(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb);
@@ -31,6 +33,8 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 	return false;
 }
 
+static inline void msft_register(struct hci_dev *hdev) {}
+static inline void msft_unregister(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb) {}
]

gemini-3.1-pro-preview

							input: 35294
							output: 33
							thoughts: 56
						

Here's my thought process, distilled:

**Tracing Down a Kernel Synchronization Bug**

Okay, so I see a potential synchronization issue. The `msft_register` function, a critical part of the Microsoft kernel driver, was introduced in commit `5031ffcc79b81`. And I also see a `mutex_init(&msft->filter_lock)` call in there later. My immediate thought is, when was the mutex itself initialized in relation to that registration? Knowing the chronology of these additions is going to be key to debugging. I need to find out precisely when that `mutex_init` was introduced. Let's dig into the commit history.

log-in to see details

map[CodeRegexp:mutex_init\(&msft->filter_lock\) Count:5]

map[Output:]

gemini-3.1-pro-preview

							input: 35561
							output: 47
							thoughts: 15
						

Okay, here's my attempt at summarizing the thought process, as if it were my own, targeted to an expert audience and starting with a bolded header:

**Diving into `net/bluetooth/msft.c`**

Alright, I'm zoning in on `net/bluetooth/msft.c`. That's where I need to start. This clearly indicates some interaction with Microsoft's Bluetooth stack, or at least a vendor-specific implementation or extension. I need to understand what specific functionality is implemented within this file. Is it related to a specific hardware, perhaps certain Microsoft Surface devices? Are there any obvious proprietary protocols or extensions being handled here, maybe something related to enhanced audio codecs, fast pairing, or even device-specific power management? The naming suggests that the intention of this file is to handle Microsoft-specific aspects of Bluetooth communication. My focus now is on what those aspects are, and how they integrate (or potentially deviate) from standard Bluetooth protocols. Let's dig in and figure out the architecture.

map[CodeRegexp:mutex_init\(&msft->filter_lock\) Count:5 PathPrefix:net/bluetooth/msft.c]

map[Output:9e14606d8f38 Bluetooth: msft: Extended monitor tracking by address filter
]

gemini-3.1-pro-preview

							input: 35874
							output: 27
							thoughts: 18
						

Okay, let's dive into this. Here's my take on that request, written from the first-person perspective, assuming I'm an expert:

**Investigating Revision `9e14606d8f38`**

Alright, time to get a grip on `9e14606d8f38`. This looks like a specific revision identifier, likely a commit hash in a version control system. My first thought is, what's the context? Where is this coming from? Is this from a recent integration, a reported bug fix, or something else entirely? Without that information, I'm already forming some assumptions based on my experience. I'm automatically thinking about what tools I'll need – a diff viewer, a code browser integrated with the repository, maybe even a debugger if I suspect some subtle behavior change. I'll need to understand the change set. What files were modified? What were the specific line-by-line alterations? Are there tests associated with this revision? I'm going to want to run those tests immediately, if so. A quick scan of the commit message is essential, but it can only offer the broad strokes. The real story is always in the code itself. I'm going to start by pulling up the changes visually, looking for any immediate red flags: unexpected dependencies, overly complex logic, or any potentially destabilizing modifications to core components. Given the nature of my expertise, I'm expecting this to be a quick process. But let's see what the code has to say.

map[Commit:9e14606d8f38]

map[Output:commit 9e14606d8f38ea52a38c27692a9c1513c987a5da
Author: Hilda Wu <hildawu@realtek.com>
Date:   Wed Jun 21 18:00:31 2023 +0800

    Bluetooth: msft: Extended monitor tracking by address filter
    
    Since limited tracking device per condition, this feature is to support
    tracking multiple devices concurrently.
    When a pattern monitor detects the device, this feature issues an address
    monitor for tracking that device. Let pattern monitor can keep monitor
    new devices.
    This feature adds an address filter when receiving a LE monitor device
    event which monitor handle is for a pattern, and the controller started
    monitoring the device. And this feature also has cancelled the monitor
    advertisement from address filters when receiving a LE monitor device
    event when the controller stopped monitoring the device specified by an
    address and monitor handle.
    
    Below is an example to know the feature adds the address filter.
    
    //Add MSFT pattern monitor
    < HCI Command: Vendor (0x3f|0x00f0) plen 14          #142 [hci0] 55.552420
            03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
    > HCI Event: Command Complete (0x0e) plen 6          #143 [hci0] 55.653960
          Vendor (0x3f|0x00f0) ncmd 2
            Status: Success (0x00)
            03 00
    
    //Got event from the pattern monitor
    > HCI Event: Vendor (0xff) plen 18                   #148 [hci0] 58.384953
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            00 01                                            ..
    
    //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
    < HCI Command: Vendor (0x3f|0x00f0) plen 13          #149 [hci0] 58.385067
            03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.
    
    //Report to userspace about found device (ADV Monitor Device Found)
    @ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
            01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
            0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
            c1 03 03 03 12 18                                ......
    
    //Got event from address monitor
    > HCI Event: Vendor (0xff) plen 18                   #152 [hci0] 58.672956
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            01 01
    
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Hilda Wu <hildawu@realtek.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 04399b3c39a0..ddae6524106d 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -1269,6 +1269,10 @@ void btrtl_set_quirks(struct hci_dev *hdev, struct btrtl_device_info *btrtl_dev)
 		if (btrtl_dev->project_id == CHIP_ID_8852C)
 			btrealtek_set_flag(hdev, REALTEK_ALT6_CONTINUOUS_TX_CHIP);
 
+		if (btrtl_dev->project_id == CHIP_ID_8852A ||
+		    btrtl_dev->project_id == CHIP_ID_8852C)
+			set_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks);
+
 		hci_set_aosp_capable(hdev);
 		break;
 	default:
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ab2f8f1817cf..5723405b833e 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -309,6 +309,16 @@ enum {
 	 * to support it.
 	 */
 	HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT,
+
+	/* When this quirk is set, MSFT extension monitor tracking by
+	 * address filter is supported. Since tracking quantity of each
+	 * pattern is limited, this feature supports tracking multiple
+	 * devices concurrently if controller supports multiple
+	 * address filters.
+	 *
+	 * This quirk must be set before hci_register_dev is called.
+	 */
+	HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER,
 };
 
 /* HCI device flags */
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index bf5cee48916c..b80a2162a5c3 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -91,6 +91,33 @@ struct msft_ev_le_monitor_device {
 struct msft_monitor_advertisement_handle_data {
 	__u8  msft_handle;
 	__u16 mgmt_handle;
+	__s8 rssi_high;
+	__s8 rssi_low;
+	__u8 rssi_low_interval;
+	__u8 rssi_sampling_period;
+	__u8 cond_type;
+	struct list_head list;
+};
+
+enum monitor_addr_filter_state {
+	AF_STATE_IDLE,
+	AF_STATE_ADDING,
+	AF_STATE_ADDED,
+	AF_STATE_REMOVING,
+};
+
+#define MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR	0x04
+struct msft_monitor_addr_filter_data {
+	__u8     msft_handle;
+	__u8     pattern_handle; /* address filters pertain to */
+	__u16    mgmt_handle;
+	int      state;
+	__s8     rssi_high;
+	__s8     rssi_low;
+	__u8     rssi_low_interval;
+	__u8     rssi_sampling_period;
+	__u8     addr_type;
+	bdaddr_t bdaddr;
 	struct list_head list;
 };
 
@@ -99,9 +126,12 @@ struct msft_data {
 	__u8  evt_prefix_len;
 	__u8  *evt_prefix;
 	struct list_head handle_map;
+	struct list_head address_filters;
 	__u8 resuming;
 	__u8 suspending;
 	__u8 filter_enabled;
+	/* To synchronize add/remove address filter and monitor device event.*/
+	struct mutex filter_lock;
 };
 
 bool msft_monitor_supported(struct hci_dev *hdev)
@@ -180,6 +210,24 @@ static struct msft_monitor_advertisement_handle_data *msft_find_handle_data
 	return NULL;
 }
 
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_find_address_data
+			(struct hci_dev *hdev, u8 addr_type, bdaddr_t *addr,
+			 u8 pattern_handle)
+{
+	struct msft_monitor_addr_filter_data *entry;
+	struct msft_data *msft = hdev->msft_data;
+
+	list_for_each_entry(entry, &msft->address_filters, list) {
+		if (entry->pattern_handle == pattern_handle &&
+		    addr_type == entry->addr_type &&
+		    !bacmp(addr, &entry->bdaddr))
+			return entry;
+	}
+
+	return NULL;
+}
+
 /* This function requires the caller holds hdev->lock */
 static int msft_monitor_device_del(struct hci_dev *hdev, __u16 mgmt_handle,
 				   bdaddr_t *bdaddr, __u8 addr_type,
@@ -240,6 +288,7 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 
 	handle_data->mgmt_handle = monitor->handle;
 	handle_data->msft_handle = rp->handle;
+	handle_data->cond_type   = MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN;
 	INIT_LIST_HEAD(&handle_data->list);
 	list_add(&handle_data->list, &msft->handle_map);
 
@@ -254,6 +303,70 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 	return status;
 }
 
+/* This function requires the caller holds hci_req_sync_lock */
+static void msft_remove_addr_filters_sync(struct hci_dev *hdev, u8 handle)
+{
+	struct msft_monitor_addr_filter_data *address_filter, *n;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct list_head head;
+	struct sk_buff *skb;
+
+	INIT_LIST_HEAD(&head);
+
+	/* Cancel all corresponding address monitors */
+	mutex_lock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		if (address_filter->pattern_handle != handle)
+			continue;
+
+		list_del(&address_filter->list);
+
+		/* Keep the address filter and let
+		 * msft_add_address_filter_sync() remove and free the address
+		 * filter.
+		 */
+		if (address_filter->state == AF_STATE_ADDING) {
+			address_filter->state = AF_STATE_REMOVING;
+			continue;
+		}
+
+		/* Keep the address filter and let
+		 * msft_cancel_address_filter_sync() remove and free the address
+		 * filter
+		 */
+		if (address_filter->state == AF_STATE_REMOVING)
+			continue;
+
+		list_add_tail(&address_filter->list, &head);
+	}
+
+	mutex_unlock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &head, list) {
+		list_del(&address_filter->list);
+
+		cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+		cp.handle = address_filter->msft_handle;
+
+		skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+				     HCI_CMD_TIMEOUT);
+		if (IS_ERR_OR_NULL(skb)) {
+			kfree(address_filter);
+			continue;
+		}
+
+		kfree_skb(skb);
+
+		bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+			   &address_filter->bdaddr);
+
+		kfree(address_filter);
+	}
+}
+
 static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						   u16 opcode,
 						   struct adv_monitor *monitor,
@@ -263,6 +376,7 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_data *msft = hdev->msft_data;
 	int status = 0;
+	u8 msft_handle;
 
 	rp = (struct msft_rp_le_cancel_monitor_advertisement *)skb->data;
 	if (skb->len < sizeof(*rp)) {
@@ -293,11 +407,17 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						NULL, 0, false);
 		}
 
+		msft_handle = handle_data->msft_handle;
+
 		list_del(&handle_data->list);
 		kfree(handle_data);
-	}
 
-	hci_dev_unlock(hdev);
+		hci_dev_unlock(hdev);
+
+		msft_remove_addr_filters_sync(hdev, msft_handle);
+	} else {
+		hci_dev_unlock(hdev);
+	}
 
 done:
 	return status;
@@ -394,12 +514,14 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 {
 	struct msft_cp_le_monitor_advertisement *cp;
 	struct msft_le_monitor_advertisement_pattern_data *pattern_data;
+	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_le_monitor_advertisement_pattern *pattern;
 	struct adv_pattern *entry;
 	size_t total_size = sizeof(*cp) + sizeof(*pattern_data);
 	ptrdiff_t offset = 0;
 	u8 pattern_count = 0;
 	struct sk_buff *skb;
+	int err;
 
 	if (!msft_monitor_pattern_valid(monitor))
 		return -EINVAL;
@@ -436,16 +558,31 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 
 	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, total_size, cp,
 			     HCI_CMD_TIMEOUT);
-	kfree(cp);
 
 	if (IS_ERR_OR_NULL(skb)) {
-		if (!skb)
-			return -EIO;
-		return PTR_ERR(skb);
+		err = PTR_ERR(skb);
+		goto out_free;
 	}
 
-	return msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
-						monitor, skb);
+	err = msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
+					       monitor, skb);
+	if (err)
+		goto out_free;
+
+	handle_data = msft_find_handle_data(hdev, monitor->handle, true);
+	if (!handle_data) {
+		err = -ENODATA;
+		goto out_free;
+	}
+
+	handle_data->rssi_high	= cp->rssi_high;
+	handle_data->rssi_low	= cp->rssi_low;
+	handle_data->rssi_low_interval	  = cp->rssi_low_interval;
+	handle_data->rssi_sampling_period = cp->rssi_sampling_period;
+
+out_free:
+	kfree(cp);
+	return err;
 }
 
 /* This function requires the caller holds hci_req_sync_lock */
@@ -538,6 +675,7 @@ void msft_do_close(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 	struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
+	struct msft_monitor_addr_filter_data *address_filter, *n;
 	struct adv_monitor *monitor;
 
 	if (!msft)
@@ -559,6 +697,14 @@ void msft_do_close(struct hci_dev *hdev)
 		kfree(handle_data);
 	}
 
+	mutex_lock(&msft->filter_lock);
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	}
+	mutex_unlock(&msft->filter_lock);
+
 	hci_dev_lock(hdev);
 
 	/* Clear any devices that are being monitored and notify device lost */
@@ -568,6 +714,49 @@ void msft_do_close(struct hci_dev *hdev)
 	hci_dev_unlock(hdev);
 }
 
+static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb;
+	int err = 0;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return 0;
+
+	mutex_lock(&msft->filter_lock);
+	list_del(&address_filter->list);
+	mutex_unlock(&msft->filter_lock);
+
+	cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+	cp.handle = address_filter->msft_handle;
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "MSFT: Failed to cancel address (%pMR) filter",
+			   &address_filter->bdaddr);
+		err = EIO;
+		goto done;
+	}
+	kfree_skb(skb);
+
+	bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+		   &address_filter->bdaddr);
+
+done:
+	kfree(address_filter);
+
+	return err;
+}
+
 void msft_register(struct hci_dev *hdev)
 {
 	struct msft_data *msft = NULL;
@@ -581,7 +770,9 @@ void msft_register(struct hci_dev *hdev)
 	}
 
 	INIT_LIST_HEAD(&msft->handle_map);
+	INIT_LIST_HEAD(&msft->address_filters);
 	hdev->msft_data = msft;
+	mutex_init(&msft->filter_lock);
 }
 
 void msft_unregister(struct hci_dev *hdev)
@@ -596,6 +787,7 @@ void msft_unregister(struct hci_dev *hdev)
 	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
+	mutex_destroy(&msft->filter_lock);
 	kfree(msft);
 }
 
@@ -645,11 +837,149 @@ static void *msft_skb_pull(struct hci_dev *hdev, struct sk_buff *skb,
 	return data;
 }
 
+static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_rp_le_monitor_advertisement *rp;
+	struct msft_cp_le_monitor_advertisement *cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb = NULL;
+	bool remove = false;
+	size_t size;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return -ENODEV;
+
+	/* We are safe to use the address filter from now on.
+	 * msft_monitor_device_evt() wouldn't delete this filter because it's
+	 * not been added by now.
+	 * And all other functions that requiring hci_req_sync_lock wouldn't
+	 * touch this filter before this func completes because it's protected
+	 * by hci_req_sync_lock.
+	 */
+
+	if (address_filter->state == AF_STATE_REMOVING) {
+		mutex_lock(&msft->filter_lock);
+		list_del(&address_filter->list);
+		mutex_unlock(&msft->filter_lock);
+		kfree(address_filter);
+		return 0;
+	}
+
+	size = sizeof(*cp) +
+	       sizeof(address_filter->addr_type) +
+	       sizeof(address_filter->bdaddr);
+	cp = kzalloc(size, GFP_KERNEL);
+	if (!cp) {
+		bt_dev_err(hdev, "MSFT: Alloc cmd param err");
+		remove = true;
+		goto done;
+	}
+	cp->sub_opcode           = MSFT_OP_LE_MONITOR_ADVERTISEMENT;
+	cp->rssi_high		 = address_filter->rssi_high;
+	cp->rssi_low		 = address_filter->rssi_low;
+	cp->rssi_low_interval    = address_filter->rssi_low_interval;
+	cp->rssi_sampling_period = address_filter->rssi_sampling_period;
+	cp->cond_type            = MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR;
+	cp->data[0]              = address_filter->addr_type;
+	memcpy(&cp->data[1], &address_filter->bdaddr,
+	       sizeof(address_filter->bdaddr));
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, size, cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "Failed to enable address %pMR filter",
+			   &address_filter->bdaddr);
+		skb = NULL;
+		remove = true;
+		goto done;
+	}
+
+	rp = skb_pull_data(skb, sizeof(*rp));
+	if (!rp || rp->sub_opcode != MSFT_OP_LE_MONITOR_ADVERTISEMENT ||
+	    rp->status)
+		remove = true;
+
+done:
+	mutex_lock(&msft->filter_lock);
+
+	if (remove) {
+		bt_dev_warn(hdev, "MSFT: Remove address (%pMR) filter",
+			    &address_filter->bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	} else {
+		address_filter->state = AF_STATE_ADDED;
+		address_filter->msft_handle = rp->handle;
+		bt_dev_dbg(hdev, "MSFT: Address %pMR filter enabled",
+			   &address_filter->bdaddr);
+	}
+	mutex_unlock(&msft->filter_lock);
+
+	kfree_skb(skb);
+
+	return 0;
+}
+
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_add_address_filter
+		(struct hci_dev *hdev, u8 addr_type, bdaddr_t *bdaddr,
+		 struct msft_monitor_advertisement_handle_data *handle_data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = NULL;
+	struct msft_data *msft = hdev->msft_data;
+	int err;
+
+	address_filter = kzalloc(sizeof(*address_filter), GFP_KERNEL);
+	if (!address_filter)
+		return NULL;
+
+	address_filter->state             = AF_STATE_ADDING;
+	address_filter->msft_handle       = 0xff;
+	address_filter->pattern_handle    = handle_data->msft_handle;
+	address_filter->mgmt_handle       = handle_data->mgmt_handle;
+	address_filter->rssi_high         = handle_data->rssi_high;
+	address_filter->rssi_low          = handle_data->rssi_low;
+	address_filter->rssi_low_interval = handle_data->rssi_low_interval;
+	address_filter->rssi_sampling_period = handle_data->rssi_sampling_period;
+	address_filter->addr_type            = addr_type;
+	bacpy(&address_filter->bdaddr, bdaddr);
+
+	/* With the above AF_STATE_ADDING, duplicated address filter can be
+	 * avoided when receiving monitor device event (found/lost) frequently
+	 * for the same device.
+	 */
+	list_add_tail(&address_filter->list, &msft->address_filters);
+
+	err = hci_cmd_sync_queue(hdev, msft_add_address_filter_sync,
+				 address_filter, NULL);
+	if (err < 0) {
+		bt_dev_err(hdev, "MSFT: Add address %pMR filter err", bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+		return NULL;
+	}
+
+	bt_dev_dbg(hdev, "MSFT: Add device %pMR address filter",
+		   &address_filter->bdaddr);
+
+	return address_filter;
+}
+
 /* This function requires the caller holds hdev->lock */
 static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 {
+	struct msft_monitor_addr_filter_data *n, *address_filter = NULL;
 	struct msft_ev_le_monitor_device *ev;
 	struct msft_monitor_advertisement_handle_data *handle_data;
+	struct msft_data *msft = hdev->msft_data;
+	u16 mgmt_handle = 0xffff;
 	u8 addr_type;
 
 	ev = msft_skb_pull(hdev, skb, MSFT_EV_LE_MONITOR_DEVICE, sizeof(*ev));
@@ -662,9 +992,53 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		   ev->monitor_state, &ev->bdaddr);
 
 	handle_data = msft_find_handle_data(hdev, ev->monitor_handle, false);
-	if (!handle_data)
+
+	if (!test_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks)) {
+		if (!handle_data)
+			return;
+		mgmt_handle = handle_data->mgmt_handle;
+		goto report_state;
+	}
+
+	if (handle_data) {
+		/* Don't report any device found/lost event from pattern
+		 * monitors. Pattern monitor always has its address filters for
+		 * tracking devices.
+		 */
+
+		address_filter = msft_find_address_data(hdev, ev->addr_type,
+							&ev->bdaddr,
+							handle_data->msft_handle);
+		if (address_filter)
+			return;
+
+		if (ev->monitor_state && handle_data->cond_type ==
+				MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN)
+			msft_add_address_filter(hdev, ev->addr_type,
+						&ev->bdaddr, handle_data);
+
 		return;
+	}
 
+	/* This device event is not from pattern monitor.
+	 * Report it if there is a corresponding address_filter for it.
+	 */
+	list_for_each_entry(n, &msft->address_filters, list) {
+		if (n->state == AF_STATE_ADDED &&
+		    n->msft_handle == ev->monitor_handle) {
+			mgmt_handle = n->mgmt_handle;
+			address_filter = n;
+			break;
+		}
+	}
+
+	if (!address_filter) {
+		bt_dev_warn(hdev, "MSFT: Unexpected device event %pMR, %u, %u",
+			    &ev->bdaddr, ev->monitor_handle, ev->monitor_state);
+		return;
+	}
+
+report_state:
 	switch (ev->addr_type) {
 	case ADDR_LE_DEV_PUBLIC:
 		addr_type = BDADDR_LE_PUBLIC;
@@ -681,12 +1055,18 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		return;
 	}
 
-	if (ev->monitor_state)
-		msft_device_found(hdev, &ev->bdaddr, addr_type,
-				  handle_data->mgmt_handle);
-	else
-		msft_device_lost(hdev, &ev->bdaddr, addr_type,
-				 handle_data->mgmt_handle);
+	if (ev->monitor_state) {
+		msft_device_found(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	} else {
+		if (address_filter && address_filter->state == AF_STATE_ADDED) {
+			address_filter->state = AF_STATE_REMOVING;
+			hci_cmd_sync_queue(hdev,
+					   msft_cancel_address_filter_sync,
+					   address_filter,
+					   NULL);
+		}
+		msft_device_lost(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	}
 }
 
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
@@ -724,7 +1104,9 @@ void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
 
 	switch (*evt) {
 	case MSFT_EV_LE_MONITOR_DEVICE:
+		mutex_lock(&msft->filter_lock);
 		msft_monitor_device_evt(hdev, skb);
+		mutex_unlock(&msft->filter_lock);
 		break;
 
 	default:
]

gemini-3.1-pro-preview

							input: 44655
							output: 38
							thoughts: 584
						

**Analyzing a Potential Race Condition in HCI Device Registration**

Okay, so looking at this patch `9e14606d8f38`, the addition of `mutex_init(&msft->filter_lock)` within `msft_register` and its inclusion in `struct msft_data` immediately catches my attention. I need to understand the implications of this.

Diving into the code, specifically the `msft_register` function, I see the initialization of the list heads: `INIT_LIST_HEAD(&msft->handle_map);` and `INIT_LIST_HEAD(&msft->address_filters);`. Then comes the assignment: `hdev->msft_data = msft;` *before* the mutex initialization with `mutex_init(&msft->filter_lock);`. Bingo! This is where the race condition likely resides.

The vulnerability stems from concurrent execution. If `msft_register` runs concurrently with `msft_do_close` (which, as I recall, can occur if `queue_work` is scheduled before `msft_register` is fully complete in `hci_register_dev`), `msft_do_close` could potentially read `hdev->msft_data`, find it non-NULL, and attempt to lock `msft->filter_lock` *before* it's been initialized. That's a classic mutex misuse, leading to unpredictable and potentially catastrophic behavior.

The fix is straightforward, really. There are two critical changes required. First, within `msft_register`, `mutex_init` *must* be called before assigning `hdev->msft_data = msft;`. Second, within `hci_register_dev`, `msft_register(hdev);` *must* be called before scheduling the work with `queue_work(hdev->req_workqueue, &hdev->power_on);`. This ensures the mutex is initialized before any potentially concurrent operations can attempt to use it.

Hold on, I need to expand the scope of my analysis. If `msft_register` is called *before* the `queue_work` call, the race with `msft_do_close` triggered by `power_on` should be eliminated. But are there other points of contention?

`hci_register_dev` is triggered when a *new* HCI device is registered. At this point, I need to consider the device's visibility. While `hci_sock_dev_event(hdev, HCI_DEV_REG)` is invoked before the work queue is scheduled, I need to consider whether userspace can access the device before the `power_on` work completes. If a user can open the device it'll invoke `hci_dev_open`, which in turn leads to `hci_dev_do_open` and finally `msft_do_open`.

Yes, this is definitely possible. Therefore, the order of operations I've identified is the *only* proper solution. Prioritizing `msft_register` and initializing the mutex *before* making the `msft` data available to the driver is the only way to avoid the race. This is why I should re-examine the `hci_register_dev` function with a more critical eye.

map[File:net/bluetooth/hci_core.c FirstLine:2610 LineCount:40]

map[Contents:2610:		list_add(&hdev->list, &hci_dev_list);
2611:		write_unlock(&hci_dev_list_lock);
2612:	
2613:		/* Devices that are marked for raw-only usage are unconfigured
2614:		 * and should not be included in normal operation.
2615:		 */
2616:		if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
2617:			hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
2618:	
2619:		/* Mark Remote Wakeup connection flag as supported if driver has wakeup
2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
]

gemini-3.1-pro-preview

							input: 46588
							output: 1168
							thoughts: 5401
						

**Analysis of Race Condition in Bluetooth HCI Device Registration**

Okay, so here's the deal: I've been digging into this Bluetooth HCI device registration process, and I think I've found a critical race condition that's causing this crash reported by syzkaller. The root cause comes down to the order of operations when a new virtual HCI device is registered, specifically with the `HCI_QUIRK_RAW_DEVICE` quirk set.

Here's the breakdown, from my perspective:

1.  **Device Creation and Quirk Setting**:  We start with a `vhci` device being created and a vendor packet with opcode `0x80` being written to it. This triggers a series of kernel calls.
2.  **`hci_register_dev` Invocation**: Ultimately, this leads to `hci_register_dev` being called to register the new HCI device. Because of the vendor-specific quirk, the flag `HCI_UNCONFIGURED` gets set.
3.  **The Work Queue Problem**: Inside `hci_register_dev`, there's a critical scheduling issue.  The function queues the `power_on` work, `queue_work(hdev->req_workqueue, &hdev->power_on);` *before* the Microsoft (MSFT) extension registration (`msft_register(hdev)`) and `idr_init(&hdev->adv_monitors_idr)`.  This is where things go south.
4.  **Concurrent Execution**:  The queued `power_on` work can start executing immediately on a different CPU or be preempted. Because the device is set with `HCI_UNCONFIGURED` flag, the `hci_power_on` function calls `hci_dev_do_close` almost immediately, which calls `msft_do_close`.
5.  **Uninitialized MSFT Data**: Meanwhile,  `msft_register` is *also* running concurrently. It's supposed to initialize the MSFT data associated with this HCI device, which includes allocating an `msft_data` struct, initializing some lists, and then initializing a mutex:
    ```c
    	msft = kzalloc_obj(*msft);
    	if (!msft) {
    		bt_dev_err(hdev, "Failed to register MSFT extension");
    		return;
    	}

    	INIT_LIST_HEAD(&msft->handle_map);
    	INIT_LIST_HEAD(&msft->address_filters);
    	hdev->msft_data = msft;
    	mutex_init(&msft->filter_lock);
    ```
    The key problem is that it is *assigning* the `msft_data` to `hdev` (`hdev->msft_data = msft;`) *before* the mutex is initialized! This assignment makes the data available for concurrent access before it is ready.
6.  **The Crash**: If `msft_do_close` (from the `power_on` work) executes between assigning the `msft_data` and initializing the mutex, it will read an initialized struct. It will then attempt to lock the uninitialized mutex `msft->filter_lock`. The kernel's debugging checks then correctly trigger an error because the mutex hasn't been properly initialized, leading to the crash. `mutex_lock(&msft->filter_lock)` on an uninitialized mutex is a recipe for disaster.

This race is pretty nasty because it depends on precise timing between work queue execution and the registration process.

**Proposed Fixes:**

To fix this, there are two primary changes that should be implemented:

1.  **Reordering in `hci_register_dev`**: The critical fix is to ensure the MSFT extension is fully initialized *before* the `power_on` work is queued. Therefore, move the MSFT registration and IDR initialization *before* the `queue_work` call:

    ```c
    	idr_init(&hdev->adv_monitors_idr);
    	msft_register(hdev);
    	queue_work(hdev->req_workqueue, &hdev->power_on);
    ```
    This guarantees that by the time the `power_on` work is scheduled and potentially executes, the necessary data structures for the MSFT extension are properly initialized. This is the more important change.

2.  **Defensive Ordering in `msft_register`**: Even if the primary fix is done, it's good practice to make the `msft_register` function more robust. Reorder the initialization within `msft_register` to prevent a partially initialized structure from

deep-reasoning

You are an experienced Linux kernel developer researching prior art for fixing a kernel bug.
You are given a bug explanation. This explanation details the root cause of the bug resulting
from debugging, but does not provide the final fix strategy. Your goal is to explore how
similar bugs were fixed in the past in the same subsystem or files.

CRITICAL: Do NOT attempt to debug the issue further or write a patch for it yourself.
Your ONLY objective is to research and provide the necessary historical context.

Use the git-log tool with the Since parameter set to "3 years" to focus on recent history.
Search for commits that address issues with similar root causes (e.g. similar missing locks,
incorrect refcounting, or similar error path bugs) in the affected files.

Your final reply must summarize your findings: what idioms, locking rules, or common patterns
should be followed when writing a fix for this bug based on how previous similar bugs were addressed.
If you find no relevant past fixes, clearly state that.

Don't make assumptions about the kernel source code (it may be different from what you assume it is).
Extensively use the provided code access tools (codesearch-*, git-*, grepper, etc)
to examine the actual source code, and confirm any assumptions.

Prefer calling several tools at the same time to save round-trips.

The crash is:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf


The explanation of the root cause of the bug is:

This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```

Based on the analysis of the root cause and historical fixes in the Bluetooth subsystem, this bug is a classic example of initialization order and premature exposure race conditions. 

When writing a fix for this bug (and similar issues in the future), the following idioms, locking rules, and common patterns should be followed:

### 1. Fully Initialize Before Exposure (The Publishing Rule)
**Pattern:** A newly allocated structure must be completely initialized (including all locks, lists, and default values) *before* its pointer is assigned to a globally or concurrently accessible variable.
**Context:** In `msft_register()`, assigning `hdev->msft_data = msft;` "publishes" the structure to other threads. Because `mutex_init(&msft->filter_lock);` was called *after* this assignment, a concurrent thread (like the `power_on` workqueue) could read the non-NULL pointer and attempt to lock an uninitialized mutex.
**Prior Art:** This is a fundamental kernel concurrency rule. For example, in commit `6fef032af009` (*"Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()"*), the subsystem was reworked to ensure that a new L2CAP channel is fully initialized and its lifetime is properly secured by the core *before* it is exposed to the accept queue where other tasks can access it. Similarly, commit `10f9f426ac6e` (*"Bluetooth: msft: fix slab-use-after-free in msft_do_close()"*) demonstrates that teardown functions like `msft_do_close()` rely on a simple `if (!hdev->msft_data)` check; if the pointer is not NULL, the teardown path assumes the structure and its locks are fully valid.

### 2. Complete Device Setup Before Scheduling Asynchronous Work
**Pattern:** All device state, extensions, and data structures must be fully initialized *before* scheduling any workqueues, timers, or exposing the device to userspace.
**Context:** In `hci_register_dev()`, `queue_work(..., &hdev->power_on)` was called before `idr_init()` and `msft_register()`. As soon as `queue_work()` is invoked, the work function can execute immediately on another CPU. If the work function relies on state that hasn't been initialized yet, it will race with the initialization code.
**Prior Art:** The Bluetooth subsystem frequently deals with asynchronous execution contexts. Previous fixes have addressed similar races by ensuring operations are strictly ordered or properly synchronized. For instance, commit `2449007d3f73` (*"Bluetooth: Avoid potential use-after-free in hci_error_reset"*) ensures that reference counts are held *before* asynchronous error handling work can race with device teardown. The correct idiom here is to move the `queue_work()` call to the very end of the initialization sequence.

### Summary for the Fix
The proposed fix perfectly aligns with kernel best practices:
1. **In `msft_register()`:** Move `hdev->msft_data = msft;` to the very end of the function, strictly after `mutex_init()`.
2. **In `hci_register_dev()`:** Move `queue_work(..., &hdev->power_on);` to execute after `msft_register()` and `idr_init()`. 

By adhering to the rule of **"Initialize completely, then publish/schedule"**, you prevent concurrent teardown paths or workqueues from observing a partially initialized state.

gemini-3.1-pro-preview

							input: 6776
							output: 45
							thoughts: 372
						

**My Investigation into Bluetooth Subsystem Initialization Races**

Okay, so I've got a tricky Bluetooth bug to tackle. Seems like there's a race condition brewing in the Bluetooth subsystem, specifically in `net/bluetooth/hci_core.c` and `net/bluetooth/msft.c`. The core issue is a workqueue (`hdev->power_on`) getting queued before the device is fully set up. We're talking about initialization order and potential use of uninitialized data, or perhaps premature access to a resource. Specifically, `msft_register` and `idr_init(&hdev->adv_monitors_idr)` haven't finished, and also `hdev->msft_data` is exposed before `mutex_init(&msft->filter_lock)` is called. That sounds like a textbook race condition, ripe for causing crashes or data corruption.

My task now is to see how similar issues have been handled in the past within this codebase. The goal is to identify common patterns, idioms, or locking strategies employed to mitigate these kinds of bugs. Essentially, I need to understand what best practices are for initializing and managing resources in this subsystem, and more importantly, how to prevent similar issues from arising in future commits.

I'm thinking a targeted `git-log` search is the way to go. I'll focus on the `net/bluetooth/` directory for any commits touching `hci_core.c` and `msft.c`. I'll specify a "since 3 years" time frame to get a reasonable scope, and the critical part will be the search criteria. I need to look for commits dealing with race conditions, initialization order problems, workqueue usage, mutex-related issues, and potentially use-after-free bugs or uninitialized variable concerns.

Initially, I'll start with `PathPrefix="net/bluetooth/"` and then experiment with `MessageRegexps` like "race", "init", "work", "order", "mutex". But I think I need to broaden my search and try "race", "use-after-free", "uninitialized", "order", "queue_work" for the `MessageRegexps` terms, and this search needs to target `net/bluetooth/hci_core.c` and `net/bluetooth/msft.c`. This search should give me a solid foundation for understanding the history of these types of issues in this area, and how the developers dealt with them. Based on those commits, I should be able to derive a set of principles for crafting a robust fix for this current problem.

map[Count:20 MessageRegexps:[race] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:b6807cfc195e Bluetooth: hci_sync: annotate data-races around hdev->req_status
1d6123102e9f Bluetooth: hci_core: Fix use-after-free in vhci_flush()
6fe26f694c82 Bluetooth: MGMT: Protect mgmt_pending list with its own lock
e6ed54e86aae Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
4d94f0555827 Bluetooth: hci_core: Fix sleeping function called from invalid context
333b4fd11e89 Bluetooth: L2CAP: Fix uaf in l2cap_connect
947ec0d002dc Bluetooth: fix use-after-free in accessing skb after sending it
2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
b938790e7054 Bluetooth: hci_codec: Fix leaking content of local_codecs
c7eaf80bfb0c Bluetooth: Fix hci_link_tx_to RCU lock usage
]

gemini-3.1-pro-preview

							input: 8029
							output: 45
							thoughts: 42
						

Okay, let's see. My first instinct, given the context, is to narrow down the search in the Bluetooth HCI core and MSFT drivers. To figure out the issue, I'm thinking of searching for key terms within the relevant files. I'll focus my investigation on those that suggest initialization, ordering of events, or queuing of work. Let's start with `net/bluetooth/hci_core.c` and `net/bluetooth/msft.c`. Specifically, I'll use grep-like searches for terms like "init", "order", and "queue_work". This should quickly point me towards the section of code responsible. I'm hoping that by targeting these functions, I can find the root of the problem.

map[Count:20 MessageRegexps:[init] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:bf4afc53b77a Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
e2d471b7806b Bluetooth: ISO: Fix not using SID from adv report
b05ce8896091 Bluetooth: hci: Remove deadcode
59437cbb5781 Bluetooth: hci_core: Fix not checking skb length on hci_scodata_packet
3fe288a8214e Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet
8f7dfe171c57 Bluetooth: hci_core: Prefer struct_size over open coded arithmetic
2e2515c1ba38 Bluetooth: hci_event: Set DISCOVERY_FINDING on SCAN_ENABLED
7c2cc5b1db50 Bluetooth: Add proper definitions for scan interval and window
2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
]

gemini-3.1-pro-preview

							input: 8519
							output: 47
							thoughts: 26
						

Okay, here's my attempt at summarizing those thoughts from an expert's perspective, using the first person and starting with a bolded header:

**Diving into Bluetooth HCI Core - Let's Find That Work Queue**

Right, so I need to understand how work is scheduled in the Bluetooth HCI core, specifically related to commands and events. My immediate thought is to start with the core implementation itself. That means I'm going to jump into `net/bluetooth/hci_core.c`. My instinct is to look for the heart of the matter - the scheduling mechanism, or where work is _queued_.

I'm thinking I'll start with a targeted search. I'll use "queue_work" as my first keyword; that's the most explicit way to find where work is being submitted to a workqueue. I also want to make the search as broad as possible, just in case a function calls into something else, or uses a specific type of work struct. The plan is to see if I can narrow it down quickly.

If that doesn't yield immediate fruit, I'll broaden my scope. "work" is a pretty generic term, but it will certainly capture anything related to managing work items and the overall flow of how work is passed off to the hardware. That's likely where I'll find the relevant logic. Essentially, I'm expecting to find either a dedicated workqueue used specifically for Bluetooth HCI tasks, or maybe some more generic system workqueue usage. Let's get searching.

map[Count:20 MessageRegexps:[queue_work] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
]

gemini-3.1-pro-preview

							input: 8952
							output: 45
							thoughts: 20
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Diving into hci_core.c: The Hunt for "Order"**

Alright, let's get down to brass tacks. I'm thinking about "order" within the context of `net/bluetooth/hci_core.c`. This suggests a need to understand the sequence of events, likely related to command handling, event processing, or potentially even data flow management within the Bluetooth HCI core. My initial instinct is to use "order" as a keyword to find all the different contexts in this file. I have to look out for common code, such as `struct hci_dev` and its member variables, as they're critical for device-specific attributes, or configurations that might be used when checking for different criteria. I have to think about synchronization primitives, like mutexes or spinlocks, that could be involved, as these would be vital to controlling "order" in a multithreaded environment. From there, I'll need to critically evaluate how "order" is *enforced* within that specific context. Is it handled explicitly through sequencing in the code, or implicitly through the kernel's scheduling or hardware interrupts? It's a broad term; it could even relate to sorting data structures, priorities, or a strict command response workflow. I'm expecting to delve deep to figure this one out!

map[Count:20 MessageRegexps:[order] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:b6807cfc195e Bluetooth: hci_sync: annotate data-races around hdev->req_status
79a2d4678ba9 Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
8f7dfe171c57 Bluetooth: hci_core: Prefer struct_size over open coded arithmetic
]

gemini-3.1-pro-preview

							input: 9438
							output: 46
							thoughts: 21
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into Bluetooth HCI Core Code**

Alright, time to dig in. I need to understand what's happening with Microsoft-related HCI interactions within the Bluetooth stack. My immediate plan is to search the `net/bluetooth/hci_core.c` file for instances of "msft." This is a pretty standard starting point when I'm tracking down vendor-specific behaviors or looking for potential workarounds. I'm expecting this search to turn up either some dedicated MSFT-specific commands, event handling tied to a Microsoft-defined profile or HCI extensions, or perhaps even just error messages that reference "msft." It's highly probable that this is related to compatibility considerations with their specific adapters or implementations. I'm hoping this search narrows down the relevant sections of code so I can then analyze the context around the "msft" references and determine the impact on the overall HCI flow. I’m prepared to broaden the search if the initial "msft" keyword is too narrow and doesn't reveal any obvious hooks, but starting here is the most logical first step.

map[Count:20 MessageRegexps:[msft] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:e6ed54e86aae Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
10f9f426ac6e Bluetooth: msft: fix slab-use-after-free in msft_do_close()
]

gemini-3.1-pro-preview

							input: 9823
							output: 26
							thoughts: 30
						

Here's my attempt at summarizing the thought process, as if I were having them:

**Initial Assessment: Code Review Required**

Okay, time to dive in. My immediate thought is, "Let's get down to business and examine these commits: `10f9f426ac6e` and `e6ed54e86aae`." This is where the work begins. I need to understand what's changed, what's been implemented, and if there are any potential issues lurking within these revisions. I'm going to start by quickly pulling them up, comparing them, and assessing for any red flags. My goal is a rapid, but thorough, initial assessment to determine if these commits merit a more in-depth code review.

map[Commit:10f9f426ac6e]

map[Output:commit 10f9f426ac6e752c8d87bf4346930ba347aaabac
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Tue Apr 30 12:20:51 2024 -0400

    Bluetooth: msft: fix slab-use-after-free in msft_do_close()
    
    Tying the msft->data lifetime to hdev by freeing it in
    hci_release_dev() to fix the following case:
    
    [use]
    msft_do_close()
      msft = hdev->msft_data;
      if (!msft)                      ...(1) <- passed.
        return;
      mutex_lock(&msft->filter_lock); ...(4) <- used after freed.
    
    [free]
    msft_unregister()
      msft = hdev->msft_data;
      hdev->msft_data = NULL;         ...(2)
      kfree(msft);                    ...(3) <- msft is freed.
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in __mutex_lock_common
    kernel/locking/mutex.c:587 [inline]
    BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
    kernel/locking/mutex.c:752
    Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309
    
    Fixes: bf6a4e30ffbd ("Bluetooth: disable advertisement filters during suspend")
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a7028d38c1f5..bc5086423ab8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2768,8 +2768,6 @@ void hci_unregister_dev(struct hci_dev *hdev)
 
 	hci_unregister_suspend_notifier(hdev);
 
-	msft_unregister(hdev);
-
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
@@ -2823,6 +2821,7 @@ void hci_release_dev(struct hci_dev *hdev)
 	hci_discovery_filter_clear(hdev);
 	hci_blocked_keys_clear(hdev);
 	hci_codec_list_clear(&hdev->local_codecs);
+	msft_release(hdev);
 	hci_dev_unlock(hdev);
 
 	ida_destroy(&hdev->unset_handle_ida);
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 9612c5d1b13f..d039683d3bdd 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -769,7 +769,7 @@ void msft_register(struct hci_dev *hdev)
 	mutex_init(&msft->filter_lock);
 }
 
-void msft_unregister(struct hci_dev *hdev)
+void msft_release(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 2a63205b377b..fe538e9c91c0 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -14,7 +14,7 @@
 
 bool msft_monitor_supported(struct hci_dev *hdev);
 void msft_register(struct hci_dev *hdev);
-void msft_unregister(struct hci_dev *hdev);
+void msft_release(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb);
@@ -35,7 +35,7 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 }
 
 static inline void msft_register(struct hci_dev *hdev) {}
-static inline void msft_unregister(struct hci_dev *hdev) {}
+static inline void msft_release(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, void *data,
]

gemini-3.1-pro-preview

							input: 11381
							output: 42
							thoughts: 277
						

**Analyzing Potential Initialization Order Bugs**

Okay, so the user's pointing out a race condition in the Bluetooth HCI core, specifically related to power-on handling and device registration. It looks like `hdev->power_on` work is getting queued before crucial initialization steps – `msft_register(hdev)` and `idr_init(&hdev->adv_monitors_idr)` are completed. Furthermore, it seems like `hdev->msft_data` is being exposed too early within `msft_register` before the mutex `msft->filter_lock` is initialized.

The proposed fix makes sense – move the `queue_work` call *after* the registration and IDR initialization and move the `hdev->msft_data` assignment *after* the mutex initialization. A valid fix, no doubt.

The user is asking me to dig deeper and look for similar initialization order bugs, specifically within the same subsystem (Bluetooth) or even the same files. My task is to find previous commits that addressed similar problems. Think missing locks, incorrect reference counting scenarios, error paths with initialization order bugs. Things that have the same root cause.

My initial approach is to focus on `net/bluetooth/hci_core.c` and search for instances of `queue_work`. This should reveal other potential initialization sequence issues that have already been identified and fixed. This will give a good starting point for investigation, and hopefully reveal some useful insights!

map[Count:20 MessageRegexps:[queue_work] PathPrefix:net/bluetooth/ Since:3 years]

map[Output:518aa9505fa1 Bluetooth: 6lowpan: hold L2CAP conn across debugfs control
2641a9e0a1dd Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock
9e622804d57e Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
]

gemini-3.1-pro-preview

							input: 12137
							output: 45
							thoughts: 22
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Revisiting `hci_core.c` for "Order"**

Okay, time to circle back to `net/bluetooth/hci_core.c`. I'm going to search for the term "order" within that file again. My gut tells me there might be something related to command sequencing, ACL/SCO packet ordering, or perhaps even queue management that I missed during the initial sweep. I'm specifically looking for any subtle nuances related to the sequence of events and how they are handled, particularly concerning HCI commands or data flow. It's a key area for potential race conditions or unexpected behavior in a Bluetooth stack, so I want to ensure my understanding of the relevant logic is rock solid. I'm mentally preparing to sift through function calls, data structures, and comments to spot any clues I might have initially overlooked. I'm anticipating that "order" might be used in a less-than-obvious context, perhaps as part of a variable name or in a string literal within a larger conditional. Time to dive in.

map[Count:20 MessageRegexps:[order] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:b6807cfc195e Bluetooth: hci_sync: annotate data-races around hdev->req_status
79a2d4678ba9 Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
8f7dfe171c57 Bluetooth: hci_core: Prefer struct_size over open coded arithmetic
]

gemini-3.1-pro-preview

							input: 12566
							output: 45
							thoughts: 20
						

Okay, here's my attempt at summarizing my thought process, assuming I'm a networking/Bluetooth kernel expert:

**Investigating Potential Race Conditions in net/bluetooth/hci_core.c**

Alright, time to dive into `net/bluetooth/hci_core.c`. My gut feeling, when someone mentions "race" in this context, immediately triggers a search for potential concurrency issues. This is Bluetooth, so multi-threaded access to shared data is almost guaranteed. I need to figure out where those interactions might occur. My first step is a simple string search. "race" is a pretty broad term, so I'm not expecting a direct hit on a problematic function name, but it should point me to relevant areas within the file that are worth a deeper look. Then, I can start thinking about specific scenarios and potential flaws in the locking mechanisms, or lack thereof. I’ll be looking for shared data structures, interrupt handlers, and any place where multiple threads or contexts might be accessing the same resources simultaneously. Let's see what that search turns up. This initial scan is just to gain context and find the most relevant areas to focus on.

map[Count:20 MessageRegexps:[race] PathPrefix:net/bluetooth/hci_core.c Since:3 years]

map[Output:b6807cfc195e Bluetooth: hci_sync: annotate data-races around hdev->req_status
1d6123102e9f Bluetooth: hci_core: Fix use-after-free in vhci_flush()
6fe26f694c82 Bluetooth: MGMT: Protect mgmt_pending list with its own lock
e6ed54e86aae Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
4d94f0555827 Bluetooth: hci_core: Fix sleeping function called from invalid context
333b4fd11e89 Bluetooth: L2CAP: Fix uaf in l2cap_connect
947ec0d002dc Bluetooth: fix use-after-free in accessing skb after sending it
2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
b938790e7054 Bluetooth: hci_codec: Fix leaking content of local_codecs
c7eaf80bfb0c Bluetooth: Fix hci_link_tx_to RCU lock usage
]

gemini-3.1-pro-preview

							input: 13161
							output: 27
							thoughts: 33
						

Okay, here's my interpretation of those thoughts, framed as a first-person summary, keeping in mind my expertise:

**Checking Specific Hashes**

Right, let's get down to brass tacks. Time to take a look at those two specific hashes: `1d6123102e9f` and `2449007d3f73`. There's likely a specific reason we're zoning in on these two – maybe they've been flagged in an investigation, or perhaps they're part of a larger analysis pipeline I'm working through. My initial thought is to cross-reference them with any existing datasets, threat intelligence feeds, or internal repositories I have access to. The context will tell the real story. Are these file hashes? Network artifacts? System identifiers? I need more information to jump to a conclusion. This could be anything from a routine check to something very urgent, and I need to treat it accordingly. Let's see what we find.

map[Commit:1d6123102e9f]

map[Output:commit 1d6123102e9fbedc8d25bf4731da6d513173e49e
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Tue Jun 17 09:58:13 2025 -0700

    Bluetooth: hci_core: Fix use-after-free in vhci_flush()
    
    syzbot reported use-after-free in vhci_flush() without repro. [0]
    
    From the splat, a thread close()d a vhci file descriptor while
    its device was being used by iotcl() on another thread.
    
    Once the last fd refcnt is released, vhci_release() calls
    hci_unregister_dev(), hci_free_dev(), and kfree() for struct
    vhci_data, which is set to hci_dev->dev->driver_data.
    
    The problem is that there is no synchronisation after unlinking
    hdev from hci_dev_list in hci_unregister_dev().  There might be
    another thread still accessing the hdev which was fetched before
    the unlink operation.
    
    We can use SRCU for such synchronisation.
    
    Let's run hci_dev_reset() under SRCU and wait for its completion
    in hci_unregister_dev().
    
    Another option would be to restore hci_dev->destruct(), which was
    removed in commit 587ae086f6e4 ("Bluetooth: Remove unused
    hci-destruct cb").  However, this would not be a good solution, as
    we should not run hci_unregister_dev() while there are in-flight
    ioctl() requests, which could lead to another data-race KCSAN splat.
    
    Note that other drivers seem to have the same problem, for exmaple,
    virtbt_remove().
    
    [0]:
    BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
    BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
    Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
    
    CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    Call Trace:
     <TASK>
     dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:408 [inline]
     print_report+0xd2/0x2b0 mm/kasan/report.c:521
     kasan_report+0x118/0x150 mm/kasan/report.c:634
     skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
     skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
     skb_queue_purge include/linux/skbuff.h:3368 [inline]
     vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69
     hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]
     hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592
     sock_do_ioctl+0xd9/0x300 net/socket.c:1190
     sock_ioctl+0x576/0x790 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fcf5b98e929
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929
    RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009
    RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528
     </TASK>
    
    Allocated by task 6535:
     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:377 [inline]
     __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
     kmalloc_noprof include/linux/slab.h:905 [inline]
     kzalloc_noprof include/linux/slab.h:1039 [inline]
     vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635
     misc_open+0x2bc/0x330 drivers/char/misc.c:161
     chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414
     do_dentry_open+0xdf0/0x1970 fs/open.c:964
     vfs_open+0x3b/0x340 fs/open.c:1094
     do_open fs/namei.c:3887 [inline]
     path_openat+0x2ee5/0x3830 fs/namei.c:4046
     do_filp_open+0x1fa/0x410 fs/namei.c:4073
     do_sys_openat2+0x121/0x1c0 fs/open.c:1437
     do_sys_open fs/open.c:1452 [inline]
     __do_sys_openat fs/open.c:1468 [inline]
     __se_sys_openat fs/open.c:1463 [inline]
     __x64_sys_openat+0x138/0x170 fs/open.c:1463
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 6535:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:247 [inline]
     __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2381 [inline]
     slab_free mm/slub.c:4643 [inline]
     kfree+0x18e/0x440 mm/slub.c:4842
     vhci_release+0xbc/0xd0 drivers/bluetooth/hci_vhci.c:671
     __fput+0x44c/0xa70 fs/file_table.c:465
     task_work_run+0x1d1/0x260 kernel/task_work.c:227
     exit_task_work include/linux/task_work.h:40 [inline]
     do_exit+0x6ad/0x22e0 kernel/exit.c:955
     do_group_exit+0x21c/0x2d0 kernel/exit.c:1104
     __do_sys_exit_group kernel/exit.c:1115 [inline]
     __se_sys_exit_group kernel/exit.c:1113 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1113
     x64_sys_call+0x21ba/0x21c0 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    The buggy address belongs to the object at ffff88807cb8d800
     which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 88 bytes inside of
     freed 1024-byte region [ffff88807cb8d800, ffff88807cb8dc00)
    
    Fixes: bf18c7118cf8 ("Bluetooth: vhci: Free driver_data on file release")
    Reported-by: syzbot+2faa4825e556199361f9@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=f62d64848fc4c7c30cd6
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index a760f05fa3fb..9fc8f544e20e 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -29,6 +29,7 @@
 #include <linux/idr.h>
 #include <linux/leds.h>
 #include <linux/rculist.h>
+#include <linux/srcu.h>
 
 #include <net/bluetooth/hci.h>
 #include <net/bluetooth/hci_drv.h>
@@ -347,6 +348,7 @@ struct adv_monitor {
 
 struct hci_dev {
 	struct list_head list;
+	struct srcu_struct srcu;
 	struct mutex	lock;
 
 	struct ida	unset_handle_ida;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 07a8b4281a39..14d7221b8ac0 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -64,7 +64,7 @@ static DEFINE_IDA(hci_index_ida);
 
 /* Get HCI device by index.
  * Device is held on return. */
-struct hci_dev *hci_dev_get(int index)
+static struct hci_dev *__hci_dev_get(int index, int *srcu_index)
 {
 	struct hci_dev *hdev = NULL, *d;
 
@@ -77,6 +77,8 @@ struct hci_dev *hci_dev_get(int index)
 	list_for_each_entry(d, &hci_dev_list, list) {
 		if (d->id == index) {
 			hdev = hci_dev_hold(d);
+			if (srcu_index)
+				*srcu_index = srcu_read_lock(&d->srcu);
 			break;
 		}
 	}
@@ -84,6 +86,22 @@ struct hci_dev *hci_dev_get(int index)
 	return hdev;
 }
 
+struct hci_dev *hci_dev_get(int index)
+{
+	return __hci_dev_get(index, NULL);
+}
+
+static struct hci_dev *hci_dev_get_srcu(int index, int *srcu_index)
+{
+	return __hci_dev_get(index, srcu_index);
+}
+
+static void hci_dev_put_srcu(struct hci_dev *hdev, int srcu_index)
+{
+	srcu_read_unlock(&hdev->srcu, srcu_index);
+	hci_dev_put(hdev);
+}
+
 /* ---- Inquiry support ---- */
 
 bool hci_discovery_active(struct hci_dev *hdev)
@@ -568,9 +586,9 @@ static int hci_dev_do_reset(struct hci_dev *hdev)
 int hci_dev_reset(__u16 dev)
 {
 	struct hci_dev *hdev;
-	int err;
+	int err, srcu_index;
 
-	hdev = hci_dev_get(dev);
+	hdev = hci_dev_get_srcu(dev, &srcu_index);
 	if (!hdev)
 		return -ENODEV;
 
@@ -592,7 +610,7 @@ int hci_dev_reset(__u16 dev)
 	err = hci_dev_do_reset(hdev);
 
 done:
-	hci_dev_put(hdev);
+	hci_dev_put_srcu(hdev, srcu_index);
 	return err;
 }
 
@@ -2433,6 +2451,11 @@ struct hci_dev *hci_alloc_dev_priv(int sizeof_priv)
 	if (!hdev)
 		return NULL;
 
+	if (init_srcu_struct(&hdev->srcu)) {
+		kfree(hdev);
+		return NULL;
+	}
+
 	hdev->pkt_type  = (HCI_DM1 | HCI_DH1 | HCI_HV1);
 	hdev->esco_type = (ESCO_HV1);
 	hdev->link_mode = (HCI_LM_ACCEPT);
@@ -2678,6 +2701,9 @@ void hci_unregister_dev(struct hci_dev *hdev)
 	list_del(&hdev->list);
 	write_unlock(&hci_dev_list_lock);
 
+	synchronize_srcu(&hdev->srcu);
+	cleanup_srcu_struct(&hdev->srcu);
+
 	disable_work_sync(&hdev->rx_work);
 	disable_work_sync(&hdev->cmd_work);
 	disable_work_sync(&hdev->tx_work);
]

gemini-3.1-pro-preview

							input: 18019
							output: 27
							thoughts: 18
						

Okay, let's dive into this. Here's my thought process on this:

**Initial Assessment of `2449007d3f73`**

Alright, the first thing I do is recognize the string `2449007d3f73`. It *looks* like a hexadecimal string, and given the context I'm usually dealing with, it's very likely a hash or identifier of some kind. Immediately, I'm thinking: is this a Git commit hash, a file checksum, a database key, or something else entirely? The length suggests it's likely a SHA-1 or MD5 hash, but I need more context to be sure. My initial gut tells me that given the nature of the hex, its likely a commit hash. I need to figure out what it represents. Is it related to a specific project, a piece of code, or a dataset? I need to start figuring out *where* this ID belongs.

map[Commit:2449007d3f73]

map[Output:commit 2449007d3f73b2842c9734f45f0aadb522daf592
Author: Ying Hsu <yinghsu@chromium.org>
Date:   Thu Jan 4 11:56:32 2024 +0000

    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.
    
    Fixes: c7741d16a57c ("Bluetooth: Perform a power cycle when receiving hardware error event")
    Signed-off-by: Ying Hsu <yinghsu@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 65601aa52e0d..2821a42cefdc 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1049,6 +1049,7 @@ static void hci_error_reset(struct work_struct *work)
 {
 	struct hci_dev *hdev = container_of(work, struct hci_dev, error_reset);
 
+	hci_dev_hold(hdev);
 	BT_DBG("%s", hdev->name);
 
 	if (hdev->hw_error)
@@ -1056,10 +1057,10 @@ static void hci_error_reset(struct work_struct *work)
 	else
 		bt_dev_err(hdev, "hardware error 0x%2.2x", hdev->hw_error_code);
 
-	if (hci_dev_do_close(hdev))
-		return;
+	if (!hci_dev_do_close(hdev))
+		hci_dev_do_open(hdev);
 
-	hci_dev_do_open(hdev);
+	hci_dev_put(hdev);
 }
 
 void hci_uuids_clear(struct hci_dev *hdev)
]

gemini-3.1-pro-preview

							input: 19161
							output: 46
							thoughts: 63
						

**My Search for Prior Art**

Okay, so the user wants me to dig up some historical solutions for this initialization order bug. Specifically, they're pointing me toward similar problems fixed within the same subsystem, or even in the same files, if possible. The core issue, as I understand it, is `queue_work` being called prematurely, before the relevant device has been fully initialized.

My initial thought is to zero in on the `net/bluetooth/` directory. That seems like the logical place to start. I'll need to use some well-defined search terms to find relevant cases, so I'll probably query for "queue_work" and "init". That combination should help me locate instances where similar initialization problems were tackled, hopefully revealing some precedent. Hopefully, searching for those keywords in that directory will give me a good starting point.

map[Count:20 MessageRegexps:[queue_work init] PathPrefix:net/bluetooth/ Since:3 years]

map[Output:2449007d3f73 Bluetooth: Avoid potential use-after-free in hci_error_reset
]

gemini-3.1-pro-preview

							input: 19489
							output: 40
							thoughts: 15
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Investigating the "Order" Within Bluetooth Networking**

Okay, so I need to understand something related to "order" within the Bluetooth networking stack. My first instinct, given my experience, is to zero in on `net/bluetooth/`. That seems like the logical starting point for investigating any ordering-related concerns within the Bluetooth protocol implementation, be it in the kernel or relevant userspace components. It's the central repository for the core Bluetooth networking code. From here, I'll be able to determine the specific area of Bluetooth that's impacted (L2CAP? HCI? Profiles?). I'll want to quickly parse through the available files and directories under that path to identify relevant files to explore and see where "order" is discussed. This could relate to packet sequencing, connection setup, command execution, or perhaps even queueing mechanisms. Let's dig in.

map[Count:20 MessageRegexps:[order] PathPrefix:net/bluetooth/ Since:3 years]

map[Output:0f8a5dcc6664 Bluetooth: sco: Fix a race condition in sco_sock_timeout()
384a4b2fef9f Bluetooth: MGMT: Fix adv monitor add failure cleanup
518aa9505fa1 Bluetooth: 6lowpan: hold L2CAP conn across debugfs control
352a59dc1f4a Bluetooth: 6lowpan: avoid untracked enable work
687617555ced Bluetooth: L2CAP: validate option length before reading conf opt value
2641a9e0a1dd Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock
9707a015fe8f Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
f50331f2a144 Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer
43c441edacf9 Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()
8c8e620467a7 Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
c5d415596cb6 Bluetooth: HIDP: serialise l2cap_unregister_user via hidp_session_sem
f958c7805b18 Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths
91b5a598b528 Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
72b8deccff17 Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame() extension handling
b819db93d73f Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready
035c25007c9e Bluetooth: hci_sync: Fix UAF in le_read_features_complete
b6807cfc195e Bluetooth: hci_sync: annotate data-races around hdev->req_status
a8d1d73c81d1 Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ
6c3ea155e5ee Bluetooth: L2CAP: Fix not tracking outstanding TX ident
79a2d4678ba9 Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
]

gemini-3.1-pro-preview

							input: 20331
							output: 27
							thoughts: 18
						

Okay, let's dive into this. Here's my thought process on encountering that code, presented as a first-person summary, keeping in mind my expertise:

**Initial Assessment: Decoding the Code**

Alright, `035c25007c9e`... First, my gut reaction is that this *looks* like a potential cryptographic hash or identifier. The hexadecimal format is a dead giveaway. The length is important; it's a 12-byte hex string (48 bits). That's not overly common, so it's a bit of a clue. My initial thoughts are: could this be a truncated hash, an identifier, or perhaps a portion of a larger data structure? It's not immediately screaming "SHA-256" or "MD5" due to its size, but those are the first algorithms I'd start mentally checking against. Time to confirm my gut feeling.

map[Commit:035c25007c9e]

map[Output:commit 035c25007c9e698bef3826070ee34bb6d778020c
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Mar 25 11:11:46 2026 -0400

    Bluetooth: hci_sync: Fix UAF in le_read_features_complete
    
    This fixes the following backtrace caused by hci_conn being freed
    before le_read_features_complete but after
    hci_le_read_remote_features_sync so hci_conn_del -> hci_cmd_sync_dequeue
    is not able to prevent it:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
    BUG: KASAN: slab-use-after-free in atomic_dec_and_test include/linux/atomic/atomic-instrumented.h:1383 [inline]
    BUG: KASAN: slab-use-after-free in hci_conn_drop include/net/bluetooth/hci_core.h:1688 [inline]
    BUG: KASAN: slab-use-after-free in le_read_features_complete+0x5b/0x340 net/bluetooth/hci_sync.c:7344
    Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52
    
    CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0xcd/0x630 mm/kasan/report.c:482
     kasan_report+0xe0/0x110 mm/kasan/report.c:595
     check_region_inline mm/kasan/generic.c:194 [inline]
     kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200
     instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
     atomic_dec_and_test include/linux/atomic/atomic-instrumented.h:1383 [inline]
     hci_conn_drop include/net/bluetooth/hci_core.h:1688 [inline]
     le_read_features_complete+0x5b/0x340 net/bluetooth/hci_sync.c:7344
     hci_cmd_sync_work+0x1ff/0x430 net/bluetooth/hci_sync.c:334
     process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257
     process_scheduled_works kernel/workqueue.c:3340 [inline]
     worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421
     kthread+0x3c5/0x780 kernel/kthread.c:463
     ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
     </TASK>
    
    Allocated by task 5932:
     kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
     kasan_save_track+0x14/0x30 mm/kasan/common.c:77
     poison_kmalloc_redzone mm/kasan/common.c:400 [inline]
     __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:417
     kmalloc_noprof include/linux/slab.h:957 [inline]
     kzalloc_noprof include/linux/slab.h:1094 [inline]
     __hci_conn_add+0xf8/0x1c70 net/bluetooth/hci_conn.c:963
     hci_conn_add_unset+0x76/0x100 net/bluetooth/hci_conn.c:1084
     le_conn_complete_evt+0x639/0x1f20 net/bluetooth/hci_event.c:5714
     hci_le_enh_conn_complete_evt+0x23d/0x380 net/bluetooth/hci_event.c:5861
     hci_le_meta_evt+0x357/0x5e0 net/bluetooth/hci_event.c:7408
     hci_event_func net/bluetooth/hci_event.c:7716 [inline]
     hci_event_packet+0x685/0x11c0 net/bluetooth/hci_event.c:7773
     hci_rx_work+0x2c9/0xeb0 net/bluetooth/hci_core.c:4076
     process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257
     process_scheduled_works kernel/workqueue.c:3340 [inline]
     worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421
     kthread+0x3c5/0x780 kernel/kthread.c:463
     ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
    
    Freed by task 5932:
     kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
     kasan_save_track+0x14/0x30 mm/kasan/common.c:77
     __kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:587
     kasan_save_free_info mm/kasan/kasan.h:406 [inline]
     poison_slab_object mm/kasan/common.c:252 [inline]
     __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284
     kasan_slab_free include/linux/kasan.h:234 [inline]
     slab_free_hook mm/slub.c:2540 [inline]
     slab_free mm/slub.c:6663 [inline]
     kfree+0x2f8/0x6e0 mm/slub.c:6871
     device_release+0xa4/0x240 drivers/base/core.c:2565
     kobject_cleanup lib/kobject.c:689 [inline]
     kobject_release lib/kobject.c:720 [inline]
     kref_put include/linux/kref.h:65 [inline]
     kobject_put+0x1e7/0x590 lib/kobject.c:737
     put_device drivers/base/core.c:3797 [inline]
     device_unregister+0x2f/0xc0 drivers/base/core.c:3920
     hci_conn_del_sysfs+0xb4/0x180 net/bluetooth/hci_sysfs.c:79
     hci_conn_cleanup net/bluetooth/hci_conn.c:173 [inline]
     hci_conn_del+0x657/0x1180 net/bluetooth/hci_conn.c:1234
     hci_disconn_complete_evt+0x410/0xa00 net/bluetooth/hci_event.c:3451
     hci_event_func net/bluetooth/hci_event.c:7719 [inline]
     hci_event_packet+0xa10/0x11c0 net/bluetooth/hci_event.c:7773
     hci_rx_work+0x2c9/0xeb0 net/bluetooth/hci_core.c:4076
     process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257
     process_scheduled_works kernel/workqueue.c:3340 [inline]
     worker_thread+0x6c8/0xf10 kernel/workqueue.c:3421
     kthread+0x3c5/0x780 kernel/kthread.c:463
     ret_from_fork+0x983/0xb10 arch/x86/kernel/process.c:158
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
    
    The buggy address belongs to the object at ffff8880796b0000
     which belongs to the cache kmalloc-8k of size 8192
    The buggy address is located 16 bytes inside of
     freed 8192-byte region [ffff8880796b0000, ffff8880796b2000)
    
    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x796b0
    head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    anon flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
    page_type: f5(slab)
    raw: 00fff00000000040 ffff88813ff27280 0000000000000000 0000000000000001
    raw: 0000000000000000 0000000000020002 00000000f5000000 0000000000000000
    head: 00fff00000000040 ffff88813ff27280 0000000000000000 0000000000000001
    head: 0000000000000000 0000000000020002 00000000f5000000 0000000000000000
    head: 00fff00000000003 ffffea0001e5ac01 00000000ffffffff 00000000ffffffff
    head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5657, tgid 5657 (dhcpcd-run-hook), ts 79819636908, free_ts 79814310558
     set_page_owner include/linux/page_owner.h:32 [inline]
     post_alloc_hook+0x1af/0x220 mm/page_alloc.c:1845
     prep_new_page mm/page_alloc.c:1853 [inline]
     get_page_from_freelist+0xd0b/0x31a0 mm/page_alloc.c:3879
     __alloc_frozen_pages_noprof+0x25f/0x2440 mm/page_alloc.c:5183
     alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2416
     alloc_slab_page mm/slub.c:3075 [inline]
     allocate_slab mm/slub.c:3248 [inline]
     new_slab+0x2c3/0x430 mm/slub.c:3302
     ___slab_alloc+0xe18/0x1c90 mm/slub.c:4651
     __slab_alloc.constprop.0+0x63/0x110 mm/slub.c:4774
     __slab_alloc_node mm/slub.c:4850 [inline]
     slab_alloc_node mm/slub.c:5246 [inline]
     __kmalloc_cache_noprof+0x477/0x800 mm/slub.c:5766
     kmalloc_noprof include/linux/slab.h:957 [inline]
     kzalloc_noprof include/linux/slab.h:1094 [inline]
     tomoyo_print_bprm security/tomoyo/audit.c:26 [inline]
     tomoyo_init_log+0xc8a/0x2140 security/tomoyo/audit.c:264
     tomoyo_supervisor+0x302/0x13b0 security/tomoyo/common.c:2198
     tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
     tomoyo_env_perm+0x191/0x200 security/tomoyo/environ.c:63
     tomoyo_environ security/tomoyo/domain.c:672 [inline]
     tomoyo_find_next_domain+0xec1/0x20b0 security/tomoyo/domain.c:888
     tomoyo_bprm_check_security security/tomoyo/tomoyo.c:102 [inline]
     tomoyo_bprm_check_security+0x12d/0x1d0 security/tomoyo/tomoyo.c:92
     security_bprm_check+0x1b9/0x1e0 security/security.c:794
     search_binary_handler fs/exec.c:1659 [inline]
     exec_binprm fs/exec.c:1701 [inline]
     bprm_execve fs/exec.c:1753 [inline]
     bprm_execve+0x81e/0x1620 fs/exec.c:1729
     do_execveat_common.isra.0+0x4a5/0x610 fs/exec.c:1859
    page last free pid 5657 tgid 5657 stack trace:
     reset_page_owner include/linux/page_owner.h:25 [inline]
     free_pages_prepare mm/page_alloc.c:1394 [inline]
     __free_frozen_pages+0x7df/0x1160 mm/page_alloc.c:2901
     discard_slab mm/slub.c:3346 [inline]
     __put_partials+0x130/0x170 mm/slub.c:3886
     qlink_free mm/kasan/quarantine.c:163 [inline]
     qlist_free_all+0x4c/0xf0 mm/kasan/quarantine.c:179
     kasan_quarantine_reduce+0x195/0x1e0 mm/kasan/quarantine.c:286
     __kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:352
     kasan_slab_alloc include/linux/kasan.h:252 [inline]
     slab_post_alloc_hook mm/slub.c:4948 [inline]
     slab_alloc_node mm/slub.c:5258 [inline]
     __kmalloc_cache_noprof+0x274/0x800 mm/slub.c:5766
     kmalloc_noprof include/linux/slab.h:957 [inline]
     tomoyo_print_header security/tomoyo/audit.c:156 [inline]
     tomoyo_init_log+0x197/0x2140 security/tomoyo/audit.c:255
     tomoyo_supervisor+0x302/0x13b0 security/tomoyo/common.c:2198
     tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
     tomoyo_env_perm+0x191/0x200 security/tomoyo/environ.c:63
     tomoyo_environ security/tomoyo/domain.c:672 [inline]
     tomoyo_find_next_domain+0xec1/0x20b0 security/tomoyo/domain.c:888
     tomoyo_bprm_check_security security/tomoyo/tomoyo.c:102 [inline]
     tomoyo_bprm_check_security+0x12d/0x1d0 security/tomoyo/tomoyo.c:92
     security_bprm_check+0x1b9/0x1e0 security/security.c:794
     search_binary_handler fs/exec.c:1659 [inline]
     exec_binprm fs/exec.c:1701 [inline]
     bprm_execve fs/exec.c:1753 [inline]
     bprm_execve+0x81e/0x1620 fs/exec.c:1729
     do_execveat_common.isra.0+0x4a5/0x610 fs/exec.c:1859
     do_execve fs/exec.c:1933 [inline]
     __do_sys_execve fs/exec.c:2009 [inline]
     __se_sys_execve fs/exec.c:2004 [inline]
     __x64_sys_execve+0x8e/0xb0 fs/exec.c:2004
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
    
    Memory state around the buggy address:
     ffff8880796aff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff8880796aff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff8880796b0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                             ^
     ffff8880796b0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8880796b0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: a106e50be74b ("Bluetooth: HCI: Add support for LL Extended Feature Set")
    Reported-by: syzbot+87badbb9094e008e0685@syzkaller.appspotmail.com
    Tested-by: syzbot+87badbb9094e008e0685@syzkaller.appspotmail.com
    Closes: https://syzbot.org/bug?extid=87badbb9094e008e0685
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Pauli Virtanen <pav@iki.fi>

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 8cbbba50e77e..ffb0ceda6f7b 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -7390,10 +7390,8 @@ static void le_read_features_complete(struct hci_dev *hdev, void *data, int err)
 
 	bt_dev_dbg(hdev, "err %d", err);
 
-	if (err == -ECANCELED)
-		return;
-
 	hci_conn_drop(conn);
+	hci_conn_put(conn);
 }
 
 static int hci_le_read_all_remote_features_sync(struct hci_dev *hdev,
@@ -7463,10 +7461,12 @@ int hci_le_read_remote_features(struct hci_conn *conn)
 	if (conn->out || (hdev->le_features[0] & HCI_LE_PERIPHERAL_FEATURES)) {
 		err = hci_cmd_sync_queue_once(hdev,
 					      hci_le_read_remote_features_sync,
-					      hci_conn_hold(conn),
+					      hci_conn_hold(hci_conn_get(conn)),
 					      le_read_features_complete);
-		if (err)
+		if (err) {
 			hci_conn_drop(conn);
+			hci_conn_put(conn);
+		}
 	} else {
 		err = -EOPNOTSUPP;
 	}
]

gemini-3.1-pro-preview

							input: 26329
							output: 44
							thoughts: 280
						

**My Analysis of Initialization Order Issues in Bluetooth Drivers**

Okay, so the user wants me to dig into past fixes to find the best way to address this initialization order bug. It looks like `queue_work()` is happening before `msft_register()` and `idr_init()` in `hci_register_dev()`, and also that `hdev->msft_data` is assigned before `mutex_init()` in `msft_register()`. Classic. I get it, these are definitely initialization order problems that could lead to race conditions or use-after-free scenarios if we're not careful.

The user is asking me to search for similar fixes. That means looking for commits that involve initialization order problems or pointer exposures in the `net/bluetooth/` or `kernel/` directories. My initial reaction is to run searches with keywords like "init," "order," "race," and maybe even terms like "dereference" and "null." I need to find patterns here, the common idioms used when resolving these types of issues.

Rather than diving directly into a search, since the fix is already proposed in the prompt, my focus shifts to understanding the rationale behind the solution in terms of best practices and prior patterns in the kernel. So, the goal is not to find a fix, but to understand how *similar* fixes were made in the past.

Essentially, I want to extract the principles from existing solutions in order to write a cleaner, more robust and future proof patch.

map[Count:20 MessageRegexps:[expose init] PathPrefix:net/bluetooth/ Since:3 years]

map[Output:6fef032af009 Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
]

gemini-3.1-pro-preview

							input: 27014
							output: 25
							thoughts: 16
						

Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:

**Analyzing the Hash `6fef032af009`**

Okay, let's take a look at `6fef032af009`. My initial reaction is to consider its format. Is it an MD5 hash, SHA-1, SHA-256, or something else entirely? The length gives some clues, but I'll need to confirm the algorithm definitively. I'm immediately thinking about tools I might want to leverage here - my go-to hash identifier or a quick online check. Then, assuming I can identify the type, I need to understand its context. Where did this come from? What system or dataset is this related to? Is it a file checksum, a password hash, a database key, or something else? Understanding the source will dramatically inform how I approach any analysis. Is there related provenance or metadata associated with it? Are there any obvious potential vulnerabilities that might be immediately apparent based on the hash algorithm type? Depending on that context, I'd likely move on to checking against known hashes in my databases and any associated reputation resources for the entity or object this represents. If it's a known malicious hash, I would likely have a few remediation steps in mind immediately. But even if it's not immediately identified, the next step is typically to start considering the implications of this hash's existence and how to get further context.

map[Commit:6fef032af009]

map[Output:commit 6fef032af0092ed5ccb767239a9ac1bc38c08a40
Author: Siwei Zhang <oss@fourdim.xyz>
Date:   Mon Jun 29 09:49:58 2026 -0400

    Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
    
    l2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after
    release_sock(parent). Once the parent lock is dropped the newly
    enqueued child socket sk is reachable via the accept queue, so another
    task can accept and free it before the callback dereferences sk,
    resulting in a use-after-free.
    
    Rework the ->new_connection() op so the core, rather than the callback,
    owns the child channel's lifetime. The op now receives a pre-allocated
    new_chan and returns an errno instead of allocating and returning a
    channel. l2cap_new_connection() allocates the child channel and links
    it into the conn list via __l2cap_chan_add() before invoking the
    callback, so the conn-list reference keeps the channel alive once
    release_sock(parent) exposes the socket to other tasks.
    
    Channel configuration that was duplicated in l2cap_sock_init() and the
    various new_connection callbacks is consolidated into
    l2cap_chan_set_defaults(), which now inherits from the parent channel
    when one is supplied.
    
    Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
    Cc: stable@kernel.org
    Assisted-by: Claude:claude-opus-4-8
    Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 1640cc9bf83a..ef6ce1c20a4f 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -617,7 +617,8 @@ struct l2cap_chan {
 struct l2cap_ops {
 	char			*name;
 
-	struct l2cap_chan	*(*new_connection) (struct l2cap_chan *chan);
+	int			(*new_connection)(struct l2cap_chan *chan,
+						  struct l2cap_chan *new_chan);
 	int			(*recv) (struct l2cap_chan * chan,
 					 struct sk_buff *skb);
 	void			(*teardown) (struct l2cap_chan *chan, int err);
@@ -882,9 +883,10 @@ static inline __u16 __next_seq(struct l2cap_chan *chan, __u16 seq)
 	return (seq + 1) % (chan->tx_win_max + 1);
 }
 
-static inline struct l2cap_chan *l2cap_chan_no_new_connection(struct l2cap_chan *chan)
+static inline int l2cap_chan_no_new_connection(struct l2cap_chan *chan,
+					       struct l2cap_chan *new_chan)
 {
-	return NULL;
+	return -EOPNOTSUPP;
 }
 
 static inline int l2cap_chan_no_recv(struct l2cap_chan *chan, struct sk_buff *skb)
@@ -961,7 +963,7 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
 void l2cap_chan_busy(struct l2cap_chan *chan, int busy);
 void l2cap_chan_rx_avail(struct l2cap_chan *chan, ssize_t rx_avail);
 int l2cap_chan_check_security(struct l2cap_chan *chan, bool initiator);
-void l2cap_chan_set_defaults(struct l2cap_chan *chan);
+void l2cap_chan_set_defaults(struct l2cap_chan *chan, struct l2cap_chan *pchan);
 int l2cap_ertm_init(struct l2cap_chan *chan);
 void l2cap_chan_add(struct l2cap_conn *conn, struct l2cap_chan *chan);
 void __l2cap_chan_add(struct l2cap_conn *conn, struct l2cap_chan *chan);
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index e7be18a3af33..d504a363a30f 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -632,7 +632,7 @@ static struct l2cap_chan *chan_create(void)
 	if (!chan)
 		return NULL;
 
-	l2cap_chan_set_defaults(chan);
+	l2cap_chan_set_defaults(chan, NULL);
 
 	chan->chan_type = L2CAP_CHAN_CONN_ORIENTED;
 	chan->mode = L2CAP_MODE_LE_FLOWCTL;
@@ -745,21 +745,6 @@ static inline void chan_ready_cb(struct l2cap_chan *chan)
 	ifup(dev->netdev);
 }
 
-static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
-{
-	struct l2cap_chan *chan;
-
-	chan = chan_create();
-	if (!chan)
-		return NULL;
-
-	chan->ops = pchan->ops;
-
-	BT_DBG("chan %p pchan %p", chan, pchan);
-
-	return chan;
-}
-
 static void unregister_dev(struct lowpan_btle_dev *dev)
 {
 	struct hci_dev *hdev = READ_ONCE(dev->hdev);
@@ -889,7 +874,6 @@ static long chan_get_sndtimeo_cb(struct l2cap_chan *chan)
 
 static const struct l2cap_ops bt_6lowpan_chan_ops = {
 	.name			= "L2CAP 6LoWPAN channel",
-	.new_connection		= chan_new_conn_cb,
 	.recv			= chan_recv_cb,
 	.close			= chan_close_cb,
 	.state_change		= chan_state_change_cb,
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4ee3b9e30c65..519cd9552d86 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -522,7 +522,10 @@ void l2cap_chan_put(struct l2cap_chan *c)
 }
 EXPORT_SYMBOL_GPL(l2cap_chan_put);
 
-void l2cap_chan_set_defaults(struct l2cap_chan *chan)
+/* Initialise @chan with default values, inheriting from the parent channel
+ * @pchan when it is given.
+ */
+void l2cap_chan_set_defaults(struct l2cap_chan *chan, struct l2cap_chan *pchan)
 {
 	chan->fcs  = L2CAP_FCS_CRC16;
 	chan->max_tx = L2CAP_DEFAULT_MAX_TX;
@@ -536,6 +539,31 @@ void l2cap_chan_set_defaults(struct l2cap_chan *chan)
 	chan->retrans_timeout = L2CAP_DEFAULT_RETRANS_TO;
 	chan->monitor_timeout = L2CAP_DEFAULT_MONITOR_TO;
 
+	if (pchan) {
+		BT_DBG("chan %p pchan %p", chan, pchan);
+
+		chan->chan_type = pchan->chan_type;
+		chan->imtu = pchan->imtu;
+		chan->omtu = pchan->omtu;
+		chan->mode = pchan->mode;
+		chan->fcs = pchan->fcs;
+		chan->max_tx = pchan->max_tx;
+		chan->tx_win = pchan->tx_win;
+		chan->tx_win_max = pchan->tx_win_max;
+		chan->sec_level = pchan->sec_level;
+		chan->conf_state = pchan->conf_state;
+		chan->flags = pchan->flags;
+		chan->tx_credits = pchan->tx_credits;
+		chan->rx_credits = pchan->rx_credits;
+
+		if (chan->chan_type == L2CAP_CHAN_FIXED) {
+			chan->scid = pchan->scid;
+			chan->dcid = pchan->scid;
+		}
+
+		return;
+	}
+
 	chan->conf_state = 0;
 	set_bit(CONF_NOT_COMPLETE, &chan->conf_state);
 
@@ -4024,6 +4052,38 @@ static inline int l2cap_command_rej(struct l2cap_conn *conn,
 	return 0;
 }
 
+/* Allocate and initialise a channel for an incoming connection.
+ *
+ * The channel inherits its configuration from @pchan and is linked into @conn
+ * before ->new_connection() runs, so the conn list reference keeps it alive if
+ * the callback exposes it (e.g. via the socket accept queue) before this
+ * returns. The l2cap_chan_create() reference is taken over by the subsystem on
+ * success and dropped here on failure.
+ */
+static struct l2cap_chan *l2cap_new_connection(struct l2cap_conn *conn,
+					       struct l2cap_chan *pchan)
+{
+	struct l2cap_chan *chan;
+
+	chan = l2cap_chan_create();
+	if (!chan)
+		return NULL;
+
+	l2cap_chan_set_defaults(chan, pchan);
+	chan->ops = pchan->ops;
+
+	__l2cap_chan_add(conn, chan);
+
+	if (pchan->ops->new_connection &&
+	    pchan->ops->new_connection(pchan, chan) < 0) {
+		l2cap_chan_del(chan, 0);
+		l2cap_chan_put(chan);
+		return NULL;
+	}
+
+	return chan;
+}
+
 static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
 			  u8 *data, u8 rsp_code)
 {
@@ -4070,7 +4130,7 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
 		goto response;
 	}
 
-	chan = pchan->ops->new_connection(pchan);
+	chan = l2cap_new_connection(conn, pchan);
 	if (!chan)
 		goto response;
 
@@ -4088,8 +4148,6 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
 	chan->psm  = psm;
 	chan->dcid = scid;
 
-	__l2cap_chan_add(conn, chan);
-
 	dcid = chan->scid;
 
 	__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
@@ -4972,7 +5030,7 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
 		goto response_unlock;
 	}
 
-	chan = pchan->ops->new_connection(pchan);
+	chan = l2cap_new_connection(conn, pchan);
 	if (!chan) {
 		result = L2CAP_CR_LE_NO_MEM;
 		goto response_unlock;
@@ -4987,8 +5045,6 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
 	chan->omtu = mtu;
 	chan->remote_mps = mps;
 
-	__l2cap_chan_add(conn, chan);
-
 	l2cap_le_flowctl_init(chan, __le16_to_cpu(req->credits));
 
 	dcid = chan->scid;
@@ -5196,7 +5252,7 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
 			continue;
 		}
 
-		chan = pchan->ops->new_connection(pchan);
+		chan = l2cap_new_connection(conn, pchan);
 		if (!chan) {
 			result = L2CAP_CR_LE_NO_MEM;
 			continue;
@@ -5211,8 +5267,6 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
 		chan->omtu = mtu;
 		chan->remote_mps = mps;
 
-		__l2cap_chan_add(conn, chan);
-
 		l2cap_ecred_init(chan, __le16_to_cpu(req->credits));
 
 		/* Init response */
@@ -7492,14 +7546,12 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
 			goto next;
 
 		l2cap_chan_lock(pchan);
-		chan = pchan->ops->new_connection(pchan);
+		chan = l2cap_new_connection(conn, pchan);
 		if (chan) {
 			bacpy(&chan->src, &hcon->src);
 			bacpy(&chan->dst, &hcon->dst);
 			chan->src_type = bdaddr_src_type(hcon);
 			chan->dst_type = dst_type;
-
-			__l2cap_chan_add(conn, chan);
 		}
 
 		l2cap_chan_unlock(pchan);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index de56ca691afa..4058ff50cc27 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -43,7 +43,8 @@ static struct bt_sock_list l2cap_sk_list = {
 static const struct proto_ops l2cap_sock_ops;
 static void l2cap_sock_init(struct sock *sk, struct sock *parent);
 static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
-				     int proto, gfp_t prio, int kern);
+				     int proto, gfp_t prio, int kern,
+				     struct l2cap_chan *chan);
 static void l2cap_sock_cleanup_listen(struct sock *parent);
 
 bool l2cap_is_socket(struct socket *sock)
@@ -1284,6 +1285,23 @@ static int l2cap_sock_recvmsg(struct socket *sock, struct msghdr *msg,
 	return err;
 }
 
+/* Release the sock's ref on chan and clear the pointer so that the ref is
+ * dropped exactly once even if both l2cap_sock_kill() and
+ * l2cap_sock_destruct() run. Setting chan->data to NULL first stops any other
+ * task from dereferencing the now-dead sock pointer.
+ */
+static void l2cap_sock_put_chan(struct sock *sk)
+{
+	struct l2cap_chan *chan = l2cap_pi(sk)->chan;
+
+	if (!chan)
+		return;
+
+	chan->data = NULL;
+	l2cap_pi(sk)->chan = NULL;
+	l2cap_chan_put(chan);
+}
+
 /* Kill socket (only if zapped and orphan)
  * Must be called on unlocked socket, with l2cap channel lock.
  */
@@ -1294,13 +1312,9 @@ static void l2cap_sock_kill(struct sock *sk)
 
 	BT_DBG("sk %p state %s", sk, state_to_string(sk->sk_state));
 
-	/* Sock is dead, so set chan data to NULL, avoid other task use invalid
-	 * sock pointer.
-	 */
-	l2cap_pi(sk)->chan->data = NULL;
-	/* Kill poor orphan */
+	l2cap_sock_put_chan(sk);
 
-	l2cap_chan_put(l2cap_pi(sk)->chan);
+	/* Kill poor orphan */
 	sock_set_flag(sk, SOCK_DEAD);
 	sock_put(sk);
 }
@@ -1543,12 +1557,13 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
 	}
 }
 
-static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
+static int l2cap_sock_new_connection_cb(struct l2cap_chan *chan,
+					struct l2cap_chan *new_chan)
 {
 	struct sock *sk, *parent = chan->data;
 
 	if (!parent)
-		return NULL;
+		return -EINVAL;
 
 	lock_sock(parent);
 
@@ -1556,25 +1571,28 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
 	if (sk_acceptq_is_full(parent)) {
 		BT_DBG("backlog full %d", parent->sk_ack_backlog);
 		release_sock(parent);
-		return NULL;
+		return -ENOBUFS;
 	}
 
 	sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP,
-			      GFP_ATOMIC, 0);
+			      GFP_ATOMIC, 0, new_chan);
 	if (!sk) {
 		release_sock(parent);
-		return NULL;
-        }
+		return -ENOMEM;
+	}
 
 	bt_sock_reclassify_lock(sk, BTPROTO_L2CAP);
 
 	l2cap_sock_init(sk, parent);
 
+	/* The conn list reference taken by l2cap_new_connection() keeps new_chan
+	 * alive once release_sock() lets another task free this socket.
+	 */
 	bt_accept_enqueue(parent, sk, false);
 
 	release_sock(parent);
 
-	return l2cap_pi(sk)->chan;
+	return 0;
 }
 
 static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
@@ -1871,10 +1889,7 @@ static void l2cap_sock_destruct(struct sock *sk)
 
 	BT_DBG("sk %p", sk);
 
-	if (l2cap_pi(sk)->chan) {
-		l2cap_pi(sk)->chan->data = NULL;
-		l2cap_chan_put(l2cap_pi(sk)->chan);
-	}
+	l2cap_sock_put_chan(sk);
 
 	list_for_each_entry_safe(rx_busy, next, &l2cap_pi(sk)->rx_busy, list) {
 		kfree_skb(rx_busy->skb);
@@ -1907,30 +1922,12 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
 	BT_DBG("sk %p", sk);
 
 	if (parent) {
-		struct l2cap_chan *pchan = l2cap_pi(parent)->chan;
-
 		sk->sk_type = parent->sk_type;
 		bt_sk(sk)->flags = bt_sk(parent)->flags;
 
-		chan->chan_type = pchan->chan_type;
-		chan->imtu = pchan->imtu;
-		chan->omtu = pchan->omtu;
-		chan->conf_state = pchan->conf_state;
-		chan->mode = pchan->mode;
-		chan->fcs  = pchan->fcs;
-		chan->max_tx = pchan->max_tx;
-		chan->tx_win = pchan->tx_win;
-		chan->tx_win_max = pchan->tx_win_max;
-		chan->sec_level = pchan->sec_level;
-		chan->flags = pchan->flags;
-		chan->tx_credits = pchan->tx_credits;
-		chan->rx_credits = pchan->rx_credits;
-
-		if (chan->chan_type == L2CAP_CHAN_FIXED) {
-			chan->scid = pchan->scid;
-			chan->dcid = pchan->scid;
-		}
-
+		/* Channel configuration is inherited from the parent by
+		 * l2cap_new_connection().
+		 */
 		security_sk_clone(parent, sk);
 	} else {
 		switch (sk->sk_type) {
@@ -1956,7 +1953,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
 			chan->mode = L2CAP_MODE_BASIC;
 		}
 
-		l2cap_chan_set_defaults(chan);
+		l2cap_chan_set_defaults(chan, NULL);
 	}
 
 	/* Default config options */
@@ -1975,10 +1972,10 @@ static struct proto l2cap_proto = {
 };
 
 static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
-				     int proto, gfp_t prio, int kern)
+				     int proto, gfp_t prio, int kern,
+				     struct l2cap_chan *chan)
 {
 	struct sock *sk;
-	struct l2cap_chan *chan;
 
 	sk = bt_sock_alloc(net, sock, &l2cap_proto, proto, prio, kern);
 	if (!sk)
@@ -1989,16 +1986,7 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
 
 	INIT_LIST_HEAD(&l2cap_pi(sk)->rx_busy);
 
-	chan = l2cap_chan_create();
-	if (!chan) {
-		sk_free(sk);
-		if (sock)
-			sock->sk = NULL;
-		return NULL;
-	}
-
-	l2cap_chan_hold(chan);
-
+	/* The sock takes ownership of the caller's reference on chan. */
 	l2cap_pi(sk)->chan = chan;
 
 	return sk;
@@ -2008,6 +1996,7 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
 			     int kern)
 {
 	struct sock *sk;
+	struct l2cap_chan *chan;
 
 	BT_DBG("sock %p", sock);
 
@@ -2022,10 +2011,16 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
 
 	sock->ops = &l2cap_sock_ops;
 
-	sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern);
-	if (!sk)
+	chan = l2cap_chan_create();
+	if (!chan)
 		return -ENOMEM;
 
+	sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern, chan);
+	if (!sk) {
+		l2cap_chan_put(chan);
+		return -ENOMEM;
+	}
+
 	l2cap_sock_init(sk, NULL);
 	bt_sock_link(&l2cap_sk_list, sk);
 	return 0;
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 031d3022cb1e..c4470958b0d5 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -3201,34 +3201,19 @@ static const struct l2cap_ops smp_chan_ops = {
 	.get_sndtimeo		= l2cap_chan_no_get_sndtimeo,
 };
 
-static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
+static inline int smp_new_conn_cb(struct l2cap_chan *chan,
+				  struct l2cap_chan *new_chan)
 {
-	struct l2cap_chan *chan;
-
-	BT_DBG("pchan %p", pchan);
-
-	chan = l2cap_chan_create();
-	if (!chan)
-		return NULL;
-
-	chan->chan_type	= pchan->chan_type;
-	chan->ops	= &smp_chan_ops;
-	chan->scid	= pchan->scid;
-	chan->dcid	= chan->scid;
-	chan->imtu	= pchan->imtu;
-	chan->omtu	= pchan->omtu;
-	chan->mode	= pchan->mode;
+	new_chan->ops = &smp_chan_ops;
 
 	/* Other L2CAP channels may request SMP routines in order to
 	 * change the security level. This means that the SMP channel
 	 * lock must be considered in its own category to avoid lockdep
 	 * warnings.
 	 */
-	atomic_set(&chan->nesting, L2CAP_NESTING_SMP);
-
-	BT_DBG("created chan %p", chan);
+	atomic_set(&new_chan->nesting, L2CAP_NESTING_SMP);
 
-	return chan;
+	return 0;
 }
 
 static const struct l2cap_ops smp_root_chan_ops = {
@@ -3288,7 +3273,7 @@ static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
 
 	l2cap_add_scid(chan, cid);
 
-	l2cap_chan_set_defaults(chan);
+	l2cap_chan_set_defaults(chan, NULL);
 
 	if (cid == L2CAP_CID_SMP) {
 		u8 bdaddr_type;
]

gemini-3.1-pro-preview

							input: 34433
							output: 44
							thoughts: 503
						

**My Analysis of Bluetooth Kernel Bug Fixes**

Alright, let's break this down. The user's asking me to think through the best approach for this bug fix, considering how similar issues have been tackled in the past. From the commits I see, the primary concern seems to revolve around concurrent access and resource lifetimes within the Bluetooth stack, specifically around `use-after-free` conditions and race conditions. I see a few key themes emerging:

1.  **SRCU and Reference Counting:** The `vhci_flush()` fix (1d6123102e9f) leverages SRCU (like a read-copy-update mechanism for synchronization) during unregistration. Then, the `hci_error_reset` fix (2449007d3f73) uses `hci_dev_hold()` / `hci_dev_put()` for reference counting to manage the lifetime of the `hci_dev` struct. These suggest synchronization primitives are crucial to protect against the premature freeing of data structures.
2.  **Initialization Order and Lifetime Management:** The `l2cap_sock_new_connection_cb()` fix (6fef032af009) is interesting. It reworks the initialization order to ensure the core owns the channel's lifetime and that the channel is fully initialized before becoming accessible to other tasks. This directly addresses the potential for a race condition when the `accept` queue is involved. The `msft_do_close()` fix (10f9f426ac6e) also ties the lifetime of `msft->data` to the `hdev` lifetime, meaning the resources are freed together to avoid a use-after-free issue.

Given the nature of the bug, which is about queueing work before initialization or exposing a pointer before the structure is fully set up, I see two core patterns I need to keep in mind.

1.  **Initialization Before Exposure:** The *first* rule is to make *absolutely* sure a data structure, especially one that might be shared across threads or accessed concurrently, is *fully* initialized before it's exposed. That means ensuring that all its constituent parts - locks, lists, any associated state, etc. - are set up before, for example, a pointer to it is made available globally or assigned to a field that's accessible by another thread.
2.  **Setup Before Scheduling:** Secondly, *all* the setup for a device or subsystem (initialization of idr structures, registration functions, etc.) needs to be done *before* scheduling any workqueues or registering it with the rest of the system. Workqueues are notorious for potential immediate execution on another CPU, meaning any initialization steps that rely on that might not be complete by the time the workqueue function runs, creating a race. This includes registration with the core subsystem.

Now, to be *thorough*, I should really search the `net/bluetooth/` directory again for any other commits containing keywords like "expose", "order", or "queue\_work". Let me run that quick query and see if anything else jumps out. It's always a good idea to confirm I'm not missing any other relevant prior art.

map[Count:20 MessageRegexps:[order init] PathPrefix:net/bluetooth/ Since:3 years]

map[Output:035c25007c9e Bluetooth: hci_sync: Fix UAF in le_read_features_complete
a8d1d73c81d1 Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ
03ddb4ac2514 Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements
5f397409f8ee Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
07a9342b94a9 Bluetooth: ISO: Send BIG Create Sync via hci_sync
7d2c7ddba623 tty: rfcomm: prefer struct_size over open coded arithmetic
8f7dfe171c57 Bluetooth: hci_core: Prefer struct_size over open coded arithmetic
806a5198c059 Bluetooth: L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ
c4585edf708e Bluetooth: hci_conn, hci_sync: Use __counted_by() to avoid -Wfamnae warnings
1c08108f3014 Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings
]

gemini-3.1-pro-preview

							input: 35972
							output: 784
							thoughts: 802
						

**My Analysis of the UAF Bug in `035c25007c9e`**

Okay, let's break this down. That commit, `035c25007c9e`, which addressed that Use-After-Free, was pretty straightforward in its fix: holding a reference to prevent the dangling pointer. But looking beyond the fix itself, let's really internalize the root cause and the *why* behind the fix, especially in the context of the Bluetooth subsystem and kernel concurrency in general.

The problem, as I see it, boils down to a classic race condition stemming from improper initialization order. Specifically: `queue_work` was called *before* `msft_register` and `idr_init`, and critically, `hdev->msft_data` was assigned prematurely, *before* the mutex was initialized. This is a textbook example.

So, digging deeper, I see three critical principles emerging, and these are key to understanding the larger picture:

1.  **"Fully Initialize Before Exposure" (Publishing Rule):** The core failure is from not having a `msft_data` fully initialized before making it available (via assignment to `hdev->msft_data`). When we allocate a new data structure (like `msft_data`), all its fields, lists, and synchronization primitives (mutexes, lists) *must* be fully initialized *before* that pointer is assigned to the `hdev->msft_data` structure. This assignment effectively "publishes" the structure to other parts of the system. If we publish prematurely, concurrent threads – like the `power_on` workqueue in this case – can access completely uninitialized memory or uninitialized locks, and boom... we crash. The commit `6fef032af009` with the L2CAP sock fix? Same principle. It ensures proper initialization and lifetime management before exposure.

2.  **"Complete Setup Before Scheduling Work/Registration":** Workqueues, timers, and device registrations are the bread and butter for asynchronous execution in the kernel. When we use any of those mechanisms, we make the device visible to potentially concurrent contexts. That means *all* the device state, including extensions like MSFT and IDRs, *must* be fully set up *before* calling `queue_work()`, or any of those functions. When `queue_work()` is called, that work can run on another CPU almost immediately, and if it tries to access state that's still being initialized after the `queue_work()` call, we have a race. That's what happened here. This is a fundamental kernel concurrency rule. In the Bluetooth subsystem, and really, across the kernel, this is why we see initialization reordering and synchronization techniques like SRCU (seen in `1d6123102e9f` "Bluetooth: hci_core: Fix use-after-free in vhci_flush()") or holding references before asynchronous tasks (`2449007d3f73` "Bluetooth: Avoid potential use-after-free in hci_error_reset").

3.  **"Defensive Programming in Error Paths/Teardown":** The crash occurred during the teardown path, triggered by `hci_power_on`. So we need teardown paths that are *robust* even when state is only *partially* initialized. But the *real* fix is actually ensuring the state is *never* partially initialized when it's visible. That commit `10f9f426ac6e` ("Bluetooth: msft: fix slab-use-after-free in msft_do_close()") is a good example of this, where `msft_do_close()` relies on checking if `msft = hdev->msft_data` is NULL. If the pointer *isn't* NULL, it assumes the structure is fully valid and all its locks are initialized. This, again, highlights the need for Rule #1, where we only assign the pointer when the structure is fully valid.

The key to preventing this issue, and the pattern to be aware of going forward, centers around this initialization ordering and the need to guarantee that no partially initialized structure is made visible to other parts of the kernel. This publishing rule is, and should be treated as, critical to correctness.

map[KernelScratchSrc:/app/workdir/cache/tmp/tmp3619804582]

core

You are an experienced Linux kernel developer tasked with creating a fix for a kernel bug.
You will be given a crash report, an initial explanation of the root cause done by another
kernel expert, and a summary of how similar bugs were fixed in the past.

Use the codeeditor tool to do code edits.
Note: you will not see your changes when looking at the code using codesearch tools.
Use the patch-diff tool to review the modifications you applied.

Your final reply should contain explanation of what you did in the patch and why
(details not present in the initial explanation of the bug).

Your fix must not just prevent the given crash, but also be the best fix for the underlying
root cause from the software engineering point of view. There can be several ways to fix the
same bug. Consider alternatives, and pick the best one. For example, additional checks may be
added at different locations/functions, it's usually better to place them earlier in the
execution to avoid multiple checks at various locations later.

Frequently the same coding mistake is done in several locations in the source code.
Check if your fix should be extended/applied to similar cases around to fix other similar bugs.
But don't go too wide, don't try to fix problems kernel-wide, fix similar issues
in the same file only.


If you are changing post-conditions of a function, consider all callers of the functions,
and if they need to be updated to handle new post-conditions. For example, if you make
a function that previously never returned a NULL, return NULL, consider if callers
need to be updated to handle NULL return value.


If you will end up removing the WARN_ON macro because the condition can legitimately happen,
add a pr_err/dev_err/... (whatever is the macro for printing runtime errors used in the file)
call that logs that the unlikely condition has happened. The pr_err/dev_err/... message
must not include "WARNING" nor "BUG" strings.


Prefer calling several tools at the same time to save round-trips.

The crash that corresponds to the bug is:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf


The explanation of the root cause of the bug is:

This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```


Historical context on how similar bugs were fixed in the past:

Based on the analysis of the root cause and historical fixes in the Bluetooth subsystem, this bug is a classic example of initialization order and premature exposure race conditions. 

When writing a fix for this bug (and similar issues in the future), the following idioms, locking rules, and common patterns should be followed:

### 1. Fully Initialize Before Exposure (The Publishing Rule)
**Pattern:** A newly allocated structure must be completely initialized (including all locks, lists, and default values) *before* its pointer is assigned to a globally or concurrently accessible variable.
**Context:** In `msft_register()`, assigning `hdev->msft_data = msft;` "publishes" the structure to other threads. Because `mutex_init(&msft->filter_lock);` was called *after* this assignment, a concurrent thread (like the `power_on` workqueue) could read the non-NULL pointer and attempt to lock an uninitialized mutex.
**Prior Art:** This is a fundamental kernel concurrency rule. For example, in commit `6fef032af009` (*"Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()"*), the subsystem was reworked to ensure that a new L2CAP channel is fully initialized and its lifetime is properly secured by the core *before* it is exposed to the accept queue where other tasks can access it. Similarly, commit `10f9f426ac6e` (*"Bluetooth: msft: fix slab-use-after-free in msft_do_close()"*) demonstrates that teardown functions like `msft_do_close()` rely on a simple `if (!hdev->msft_data)` check; if the pointer is not NULL, the teardown path assumes the structure and its locks are fully valid.

### 2. Complete Device Setup Before Scheduling Asynchronous Work
**Pattern:** All device state, extensions, and data structures must be fully initialized *before* scheduling any workqueues, timers, or exposing the device to userspace.
**Context:** In `hci_register_dev()`, `queue_work(..., &hdev->power_on)` was called before `idr_init()` and `msft_register()`. As soon as `queue_work()` is invoked, the work function can execute immediately on another CPU. If the work function relies on state that hasn't been initialized yet, it will race with the initialization code.
**Prior Art:** The Bluetooth subsystem frequently deals with asynchronous execution contexts. Previous fixes have addressed similar races by ensuring operations are strictly ordered or properly synchronized. For instance, commit `2449007d3f73` (*"Bluetooth: Avoid potential use-after-free in hci_error_reset"*) ensures that reference counts are held *before* asynchronous error handling work can race with device teardown. The correct idiom here is to move the `queue_work()` call to the very end of the initialization sequence.

### Summary for the Fix
The proposed fix perfectly aligns with kernel best practices:
1. **In `msft_register()`:** Move `hdev->msft_data = msft;` to the very end of the function, strictly after `mutex_init()`.
2. **In `hci_register_dev()`:** Move `queue_work(..., &hdev->power_on);` to execute after `msft_register()` and `idr_init()`. 

By adhering to the rule of **"Initialize completely, then publish/schedule"**, you prevent concurrent teardown paths or workqueues from observing a partially initialized state.

### Summary of Changes

1. **Reorder Device Registration and Workqueue Scheduling (`net/bluetooth/hci_core.c`):**
   In `hci_register_dev()`, scheduling `&hdev->power_on` on the request workqueue was previously done *before* initializing the advertisement monitor IDR (`idr_init(&hdev->adv_monitors_idr)`) and Microsoft extension state (`msft_register(hdev)`). For devices marked with quirks like `HCI_QUIRK_RAW_DEVICE` (flagged as `HCI_UNCONFIGURED`), the asynchronously scheduled `hci_power_on` worker immediately triggers `hci_dev_do_close()` and `msft_do_close()`. By moving `queue_work(hdev->req_workqueue, &hdev->power_on)` to after `idr_init()` and `msft_register()`, the device data structures and extensions are guaranteed to be fully initialized before any asynchronous work or cleanup routines can access them.

2. **Publish MSFT Extension State After Complete Initialization (`net/bluetooth/msft.c`):**
   In `msft_register()`, `hdev->msft_data = msft;` was previously assigned before initializing the `filter_lock` mutex (`mutex_init(&msft->filter_lock)`). This exposed a partially initialized `struct msft_data` instance to concurrent teardown and callback paths (such as `msft_do_close()`), resulting in a lock attempt on an uninitialized mutex (`DEBUG_LOCKS_WARN_ON(lock->magic != lock)`). We moved the assignment `hdev->msft_data = msft;` to the very end of `msft_register()` after all list heads and mutexes have been initialized.

gemini-3.7-flash

							input: 8099
							output: 74
							thoughts: 60
						

**Initial Investigation of the Bluetooth Issue**

Okay, let's dive into this. The bug report points to specific files and lines, so that's where I need to start. I'm going to leverage my usual approach. I'll use either `read-file` or `codesearch-definition-source` to quickly get a look at `net/bluetooth/hci_core.c` and `net/bluetooth/msft.c`. This will give me a first pass at the relevant code and help me understand the context around the reported issue. No point in blindly digging without a proper look first.

map[File:net/bluetooth/hci_core.c FirstLine:2600 LineCount:50]

map[Contents:2600:	
2601:		hci_dev_set_flag(hdev, HCI_SETUP);
2602:		hci_dev_set_flag(hdev, HCI_AUTO_OFF);
2603:	
2604:		/* Assume BR/EDR support until proven otherwise (such as
2605:		 * through reading supported features during init.
2606:		 */
2607:		hci_dev_set_flag(hdev, HCI_BREDR_ENABLED);
2608:	
2609:		write_lock(&hci_dev_list_lock);
2610:		list_add(&hdev->list, &hci_dev_list);
2611:		write_unlock(&hci_dev_list_lock);
2612:	
2613:		/* Devices that are marked for raw-only usage are unconfigured
2614:		 * and should not be included in normal operation.
2615:		 */
2616:		if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
2617:			hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
2618:	
2619:		/* Mark Remote Wakeup connection flag as supported if driver has wakeup
2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
]

map[File:net/bluetooth/msft.c FirstLine:750 LineCount:30]

map[Contents: 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
]

gemini-3.7-flash

							input: 9531
							output: 39
							thoughts: 60
						

**Deep Dive into `hci_register_dev`**

Okay, let's take a comprehensive look at this. Before we dive into any specific area, I need to zoom out. I'm going to scrutinize the entire `hci_register_dev` function and the code surrounding it. My expert intuition tells me that if there's a problem in one spot, it's likely there could be related issues or at least similar patterns elsewhere. I need to ensure we're not missing something related.

Right, let's get down to brass tacks. I'll focus on lines 2500 through 2650 of the code. This should give me a solid chunk to work with. I need to thoroughly understand what's happening within this particular block of code. I'm looking for anything that might raise a red flag and potentially lead to the problem we suspect.

map[File:net/bluetooth/hci_core.c FirstLine:2500 LineCount:100]

map[Contents:2500:		INIT_LIST_HEAD(&hdev->pend_le_conns);
2501:		INIT_LIST_HEAD(&hdev->pend_le_reports);
2502:		INIT_LIST_HEAD(&hdev->conn_hash.list);
2503:		INIT_LIST_HEAD(&hdev->adv_instances);
2504:		INIT_LIST_HEAD(&hdev->blocked_keys);
2505:		INIT_LIST_HEAD(&hdev->monitored_devices);
2506:	
2507:		INIT_LIST_HEAD(&hdev->local_codecs);
2508:		INIT_WORK(&hdev->rx_work, hci_rx_work);
2509:		INIT_WORK(&hdev->cmd_work, hci_cmd_work);
2510:		INIT_WORK(&hdev->tx_work, hci_tx_work);
2511:		INIT_WORK(&hdev->power_on, hci_power_on);
2512:		INIT_WORK(&hdev->error_reset, hci_error_reset);
2513:	
2514:		hci_cmd_sync_init(hdev);
2515:	
2516:		INIT_DELAYED_WORK(&hdev->power_off, hci_power_off);
2517:	
2518:		skb_queue_head_init(&hdev->rx_q);
2519:		skb_queue_head_init(&hdev->cmd_q);
2520:		skb_queue_head_init(&hdev->raw_q);
2521:	
2522:		init_waitqueue_head(&hdev->req_wait_q);
2523:	
2524:		INIT_DELAYED_WORK(&hdev->cmd_timer, hci_cmd_timeout);
2525:		INIT_DELAYED_WORK(&hdev->ncmd_timer, hci_ncmd_timeout);
2526:	
2527:		hci_devcd_setup(hdev);
2528:	
2529:		hci_init_sysfs(hdev);
2530:		discovery_init(hdev);
2531:	
2532:		return hdev;
2533:	}
2534:	EXPORT_SYMBOL(hci_alloc_dev_priv);
2535:	
2536:	/* Free HCI device */
2537:	void hci_free_dev(struct hci_dev *hdev)
2538:	{
2539:		/* will free via device release */
2540:		put_device(&hdev->dev);
2541:	}
2542:	EXPORT_SYMBOL(hci_free_dev);
2543:	
2544:	/* Register HCI device */
2545:	int hci_register_dev(struct hci_dev *hdev)
2546:	{
2547:		int id, error;
2548:	
2549:		if (!hdev->open || !hdev->close || !hdev->send)
2550:			return -EINVAL;
2551:	
2552:		id = ida_alloc_max(&hci_index_ida, HCI_MAX_ID - 1, GFP_KERNEL);
2553:		if (id < 0)
2554:			return id;
2555:	
2556:		error = dev_set_name(&hdev->dev, "hci%u", id);
2557:		if (error)
2558:			return error;
2559:	
2560:		hdev->name = dev_name(&hdev->dev);
2561:		hdev->id = id;
2562:	
2563:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2564:	
2565:		hdev->workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI, hdev->name);
2566:		if (!hdev->workqueue) {
2567:			error = -ENOMEM;
2568:			goto err;
2569:		}
2570:	
2571:		hdev->req_workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI,
2572:							      hdev->name);
2573:		if (!hdev->req_workqueue) {
2574:			destroy_workqueue(hdev->workqueue);
2575:			error = -ENOMEM;
2576:			goto err;
2577:		}
2578:	
2579:		if (!IS_ERR_OR_NULL(bt_debugfs))
2580:			hdev->debugfs = debugfs_create_dir(hdev->name, bt_debugfs);
2581:	
2582:		error = device_add(&hdev->dev);
2583:		if (error < 0)
2584:			goto err_wqueue;
2585:	
2586:		hci_leds_init(hdev);
2587:	
2588:		hdev->rfkill = rfkill_alloc(hdev->name, &hdev->dev,
2589:					    RFKILL_TYPE_BLUETOOTH, &hci_rfkill_ops,
2590:					    hdev);
2591:		if (hdev->rfkill) {
2592:			if (rfkill_register(hdev->rfkill) < 0) {
2593:				rfkill_destroy(hdev->rfkill);
2594:				hdev->rfkill = NULL;
2595:			}
2596:		}
2597:	
2598:		if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
2599:			hci_dev_set_flag(hdev, HCI_RFKILLED);
]

gemini-3.7-flash

							input: 11419
							output: 40
							thoughts: 64
						

Okay, here's my take on those thoughts, framed as my own mental process, given my expertise:

**Diving Deep into Extension Lifecycle**

Right, so I need to get a really solid grasp on how these extensions, particularly `adv_monitors_idr`, `msft`, and `aosp`, are brought online and then properly decommissioned. I know these can be tricky, especially in a complex system like this one. Initialization and teardown are critical for avoiding resource leaks and unexpected behavior down the line. I need to understand the sequencing and dependencies involved.

My immediate plan is to zero in on the `net/bluetooth/` directory. That seems like the logical place to start digging into the core Bluetooth functionality where these extensions would likely be integrated. I'm going to leverage my grep skills – I'll search for `msft_`, `aosp_`, and `adv_monitor` specifically within that directory. This should give me a manageable set of files to review, allowing me to pinpoint the relevant initialization and cleanup routines. This targeted approach will provide me with a clean picture of how these extensions are managed in the Bluetooth stack.

map[Expression:msft_register|aosp_register|adv_monitors_idr PathPrefix:net/bluetooth]

map[Output:net/bluetooth/hci_core.c=1841=void hci_adv_monitors_clear(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-1845-
net/bluetooth/hci_core.c:1846:	idr_for_each_entry(&hdev->adv_monitors_idr, monitor, handle)
net/bluetooth/hci_core.c-1847-		hci_free_adv_monitor(hdev, monitor);
net/bluetooth/hci_core.c-1848-
net/bluetooth/hci_core.c:1849:	idr_destroy(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c-1850-}
--
net/bluetooth/hci_core.c=1855=void hci_free_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
--
net/bluetooth/hci_core.c-1868-	if (monitor->handle)
net/bluetooth/hci_core.c:1869:		idr_remove(&hdev->adv_monitors_idr, monitor->handle);
net/bluetooth/hci_core.c-1870-
--
net/bluetooth/hci_core.c=1881=int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
--
net/bluetooth/hci_core.c-1892-	max = HCI_MIN_ADV_MONITOR_HANDLE + HCI_MAX_ADV_MONITOR_NUM_HANDLES;
net/bluetooth/hci_core.c:1893:	handle = idr_alloc(&hdev->adv_monitors_idr, monitor, min, max,
net/bluetooth/hci_core.c-1894-			   GFP_KERNEL);
--
net/bluetooth/hci_core.c=1963=int hci_remove_single_adv_monitor(struct hci_dev *hdev, u16 handle)
net/bluetooth/hci_core.c-1964-{
net/bluetooth/hci_core.c:1965:	struct adv_monitor *monitor = idr_find(&hdev->adv_monitors_idr, handle);
net/bluetooth/hci_core.c-1966-
--
net/bluetooth/hci_core.c=1974=int hci_remove_all_adv_monitor(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-1980-	while (1) {
net/bluetooth/hci_core.c:1981:		monitor = idr_get_next(&hdev->adv_monitors_idr, &idr_next_id);
net/bluetooth/hci_core.c-1982-		if (!monitor)
--
net/bluetooth/hci_core.c=1996=bool hci_is_adv_monitoring(struct hci_dev *hdev)
net/bluetooth/hci_core.c-1997-{
net/bluetooth/hci_core.c:1998:	return !idr_is_empty(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c-1999-}
--
net/bluetooth/hci_core.c=2545=int hci_register_dev(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-2633-
net/bluetooth/hci_core.c:2634:	idr_init(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c:2635:	msft_register(hdev);
net/bluetooth/hci_core.c-2636-
--
net/bluetooth/hci_event.c=6174=static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
--
net/bluetooth/hci_event.c-6300-					       bdaddr, bdaddr_type) &&
net/bluetooth/hci_event.c:6301:		    idr_is_empty(&hdev->adv_monitors_idr))
net/bluetooth/hci_event.c-6302-			return;
--
net/bluetooth/hci_sync.c=2840=static u8 hci_update_accept_list_sync(struct hci_dev *hdev)
--
net/bluetooth/hci_sync.c-2994-	 */
net/bluetooth/hci_sync.c:2995:	if (!idr_is_empty(&hdev->adv_monitors_idr) && !hdev->suspended &&
net/bluetooth/hci_sync.c-2996-	    hci_get_adv_monitor_offload_ext(hdev) == HCI_ADV_MONITOR_EXT_NONE &&
--
net/bluetooth/mgmt.c=5362=static int read_adv_mon_features(struct sock *sk, struct hci_dev *hdev,
--
net/bluetooth/mgmt.c-5380-
net/bluetooth/mgmt.c:5381:	idr_for_each_entry(&hdev->adv_monitors_idr, monitor, handle)
net/bluetooth/mgmt.c-5382-		handles[num_handles++] = monitor->handle;
--
net/bluetooth/msft.c=449=int msft_suspend_sync(struct hci_dev *hdev)
--
net/bluetooth/msft.c-460-	while (1) {
net/bluetooth/msft.c:461:		monitor = idr_get_next(&hdev->adv_monitors_idr, &handle);
net/bluetooth/msft.c-462-		if (!monitor)
--
net/bluetooth/msft.c=582=static void reregister_monitor(struct hci_dev *hdev)
--
net/bluetooth/msft.c-593-	while (1) {
net/bluetooth/msft.c:594:		monitor = idr_get_next(&hdev->adv_monitors_idr, &handle);
net/bluetooth/msft.c-595-		if (!monitor)
--
net/bluetooth/msft.c=667=void msft_do_close(struct hci_dev *hdev)
--
net/bluetooth/msft.c-682-	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
net/bluetooth/msft.c:683:		monitor = idr_find(&hdev->adv_monitors_idr,
net/bluetooth/msft.c-684-				   handle_data->mgmt_handle);
--
net/bluetooth/msft.c=710=static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
--
net/bluetooth/msft.c-752-
net/bluetooth/msft.c:753:void msft_register(struct hci_dev *hdev)
net/bluetooth/msft.c-754-{
--
net/bluetooth/msft.h=15=bool msft_monitor_supported(struct hci_dev *hdev);
net/bluetooth/msft.h:16:void msft_register(struct hci_dev *hdev);
net/bluetooth/msft.h-17-void msft_release(struct hci_dev *hdev);
--
net/bluetooth/msft.h=32=static inline bool msft_monitor_supported(struct hci_dev *hdev)
--
net/bluetooth/msft.h-36-
net/bluetooth/msft.h:37:static inline void msft_register(struct hci_dev *hdev) {}
net/bluetooth/msft.h-38-static inline void msft_release(struct hci_dev *hdev) {}
]

gemini-3.7-flash

							input: 13753
							output: 26
							thoughts: 22
						

Here's my take on those thoughts:

**Considering AOSP Extensions**

Okay, so we're looking at this particular feature, and it's got me thinking. We can't just limit our investigation; to be thorough, we need to cross-reference with the Android Open Source Project. Let's dig into the `aosp` extensions. I want to see if they're implementing something analogous, some solution that might be a precedent or a related approach. A comparison could provide valuable context, and, as an expert, I know the value of examining all angles. So, let's dive into the `aosp` code and see what we can find. It's time to broaden the search.

map[Expression:aosp_ PathPrefix:net/bluetooth]

map[Output:net/bluetooth/aosp.c-16- */
net/bluetooth/aosp.c:17:struct aosp_rp_le_get_vendor_capa {
net/bluetooth/aosp.c-18-	/* v0.95: 15 octets */
--
net/bluetooth/aosp.c-42-
net/bluetooth/aosp.c:43:void aosp_do_open(struct hci_dev *hdev)
net/bluetooth/aosp.c-44-{
net/bluetooth/aosp.c-45-	struct sk_buff *skb;
net/bluetooth/aosp.c:46:	struct aosp_rp_le_get_vendor_capa *rp;
net/bluetooth/aosp.c-47-	u16 version_supported;
net/bluetooth/aosp.c-48-
net/bluetooth/aosp.c:49:	if (!hdev->aosp_capable)
net/bluetooth/aosp.c-50-		return;
--
net/bluetooth/aosp.c-69-
net/bluetooth/aosp.c:70:	rp = (struct aosp_rp_le_get_vendor_capa *)skb->data;
net/bluetooth/aosp.c-71-
--
net/bluetooth/aosp.c-97-	if (rp->bluetooth_quality_report_support) {
net/bluetooth/aosp.c:98:		hdev->aosp_quality_report = true;
net/bluetooth/aosp.c-99-		bt_dev_info(hdev, "AOSP quality report is supported");
--
net/bluetooth/aosp.c-110-
net/bluetooth/aosp.c:111:void aosp_do_close(struct hci_dev *hdev)
net/bluetooth/aosp.c-112-{
net/bluetooth/aosp.c:113:	if (!hdev->aosp_capable)
net/bluetooth/aosp.c-114-		return;
--
net/bluetooth/aosp.c-140-
net/bluetooth/aosp.c:141:struct aosp_bqr_cp {
net/bluetooth/aosp.c-142-	__u8	report_action;
--
net/bluetooth/aosp.c=147=static int enable_quality_report(struct hci_dev *hdev)
--
net/bluetooth/aosp.c-149-	struct sk_buff *skb;
net/bluetooth/aosp.c:150:	struct aosp_bqr_cp cp;
net/bluetooth/aosp.c-151-
--
net/bluetooth/aosp.c=171=static int disable_quality_report(struct hci_dev *hdev)
--
net/bluetooth/aosp.c-173-	struct sk_buff *skb;
net/bluetooth/aosp.c:174:	struct aosp_bqr_cp cp = { 0 };
net/bluetooth/aosp.c-175-
--
net/bluetooth/aosp.c-192-
net/bluetooth/aosp.c:193:bool aosp_has_quality_report(struct hci_dev *hdev)
net/bluetooth/aosp.c-194-{
net/bluetooth/aosp.c:195:	return hdev->aosp_quality_report;
net/bluetooth/aosp.c-196-}
net/bluetooth/aosp.c-197-
net/bluetooth/aosp.c:198:int aosp_set_quality_report(struct hci_dev *hdev, bool enable)
net/bluetooth/aosp.c-199-{
net/bluetooth/aosp.c:200:	if (!aosp_has_quality_report(hdev))
net/bluetooth/aosp.c-201-		return -EOPNOTSUPP;
--
net/bluetooth/aosp.h-7-
net/bluetooth/aosp.h:8:void aosp_do_open(struct hci_dev *hdev);
net/bluetooth/aosp.h:9:void aosp_do_close(struct hci_dev *hdev);
net/bluetooth/aosp.h-10-
net/bluetooth/aosp.h:11:bool aosp_has_quality_report(struct hci_dev *hdev);
net/bluetooth/aosp.h:12:int aosp_set_quality_report(struct hci_dev *hdev, bool enable);
net/bluetooth/aosp.h-13-
--
net/bluetooth/aosp.h-15-
net/bluetooth/aosp.h:16:static inline void aosp_do_open(struct hci_dev *hdev) {}
net/bluetooth/aosp.h:17:static inline void aosp_do_close(struct hci_dev *hdev) {}
net/bluetooth/aosp.h-18-
net/bluetooth/aosp.h:19:static inline bool aosp_has_quality_report(struct hci_dev *hdev)
net/bluetooth/aosp.h-20-{
--
net/bluetooth/aosp.h-23-
net/bluetooth/aosp.h:24:static inline int aosp_set_quality_report(struct hci_dev *hdev, bool enable)
net/bluetooth/aosp.h-25-{
--
net/bluetooth/hci_sync.c=5230=static int hci_dev_init_sync(struct hci_dev *hdev)
--
net/bluetooth/hci_sync.c-5273-		msft_do_open(hdev);
net/bluetooth/hci_sync.c:5274:		aosp_do_open(hdev);
net/bluetooth/hci_sync.c-5275-	}
--
net/bluetooth/hci_sync.c=5432=int hci_dev_close_sync(struct hci_dev *hdev)
--
net/bluetooth/hci_sync.c-5520-	if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
net/bluetooth/hci_sync.c:5521:		aosp_do_close(hdev);
net/bluetooth/hci_sync.c-5522-		msft_do_close(hdev);
--
net/bluetooth/mgmt.c=4613=static int read_exp_features_info(struct sock *sk, struct hci_dev *hdev,
--
net/bluetooth/mgmt.c-4648-
net/bluetooth/mgmt.c:4649:	if (hdev && (aosp_has_quality_report(hdev) ||
net/bluetooth/mgmt.c-4650-		     hdev->set_quality_report)) {
--
net/bluetooth/mgmt.c=4850=static int set_quality_report_func(struct sock *sk, struct hci_dev *hdev,
--
net/bluetooth/mgmt.c-4880-
net/bluetooth/mgmt.c:4881:	if (!aosp_has_quality_report(hdev) && !hdev->set_quality_report) {
net/bluetooth/mgmt.c-4882-		err = mgmt_cmd_status(sk, hdev->id,
--
net/bluetooth/mgmt.c-4891-		else
net/bluetooth/mgmt.c:4892:			err = aosp_set_quality_report(hdev, val);
net/bluetooth/mgmt.c-4893-
]

gemini-3.7-flash

							input: 15851
							output: 37
							thoughts: 63
						

Here's my analysis of what you're asking me to think about, framed as a first-person summary:

**Diving into the Microsoft Bluetooth Code**

Okay, so we're looking at `net/bluetooth/msft.c` again. My focus is on the crucial functions: `msft_do_close`, `msft_register`, and `msft_release`. These are the key pieces for managing the Microsoft-specific Bluetooth functionality within the kernel. I need to understand their interactions and dependencies fully.

Specifically, I'm zeroing in on lines 660 through 790. This range likely encapsulates the core logic where these functions are defined or heavily utilized. I'll be meticulously examining the code within that block to grasp the specific implementation details, any potential race conditions, resource management, or error handling nuances related to these Microsoft-specific Bluetooth operations. My goal is to develop a robust mental model of how these functions fit into the larger Bluetooth driver architecture, and to flag any potential areas for improvement or concern.

map[File:net/bluetooth/msft.c FirstLine:660 LineCount:120]

map[Contents: 660:			/* Monitors get removed on power off, so we need to explicitly
 661:			 * tell the controller to re-monitor.
 662:			 */
 663:			reregister_monitor(hdev);
 664:		}
 665:	}
 666:	
 667:	void msft_do_close(struct hci_dev *hdev)
 668:	{
 669:		struct msft_data *msft = hdev->msft_data;
 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
 700:	
 701:		hci_dev_lock(hdev);
 702:	
 703:		/* Clear any devices that are being monitored and notify device lost */
 704:		hdev->advmon_pend_notify = false;
 705:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 706:	
 707:		hci_dev_unlock(hdev);
 708:	}
 709:	
 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
 715:		struct sk_buff *skb;
 716:		int err = 0;
 717:	
 718:		if (!msft) {
 719:			bt_dev_err(hdev, "MSFT: msft data is freed");
 720:			return -EINVAL;
 721:		}
 722:	
 723:		/* The address filter has been removed by hci dev close */
 724:		if (!test_bit(HCI_UP, &hdev->flags))
 725:			return 0;
 726:	
 727:		mutex_lock(&msft->filter_lock);
 728:		list_del(&address_filter->list);
 729:		mutex_unlock(&msft->filter_lock);
 730:	
 731:		cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
 732:		cp.handle = address_filter->msft_handle;
 733:	
 734:		skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
 735:				     HCI_CMD_TIMEOUT);
 736:		if (IS_ERR(skb)) {
 737:			bt_dev_err(hdev, "MSFT: Failed to cancel address (%pMR) filter",
 738:				   &address_filter->bdaddr);
 739:			err = PTR_ERR(skb);
 740:			goto done;
 741:		}
 742:		kfree_skb(skb);
 743:	
 744:		bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
 745:			   &address_filter->bdaddr);
 746:	
 747:	done:
 748:		kfree(address_filter);
 749:	
 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
]

gemini-3.7-flash

							input: 17702
							output: 36
							thoughts: 25
						

Here's a summary of my thought process, as requested:

**Diving into `msft.c`**

Okay, time to dig in. Based on what I'm looking at, the next logical step is to examine lines 760 to 800 in `net/bluetooth/msft.c`. That section likely pertains to the specific behavior I'm trying to understand, or at least, that's where I need to start my investigation. Given the file and function I'm currently assessing, this range probably contains the relevant logic or data structures I need to analyze. Let's see what gems are hidden in those lines! I'm expecting to find either a clear implementation of the interaction I'm interested in, or at least, some clues that will help me work out the problem.

map[File:net/bluetooth/msft.c FirstLine:760 LineCount:40]

map[Contents: 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
 780:		hdev->msft_data = NULL;
 781:	
 782:		kfree(msft->evt_prefix);
 783:		mutex_destroy(&msft->filter_lock);
 784:		kfree(msft);
 785:	}
 786:	
 787:	/* This function requires the caller holds hdev->lock */
 788:	static void msft_device_found(struct hci_dev *hdev, bdaddr_t *bdaddr,
 789:				      __u8 addr_type, __u16 mgmt_handle)
 790:	{
 791:		struct monitored_device *dev;
 792:	
 793:		dev = kmalloc_obj(*dev);
 794:		if (!dev) {
 795:			bt_dev_err(hdev, "MSFT vendor event %u: no memory",
 796:				   MSFT_EV_LE_MONITOR_DEVICE);
 797:			return;
 798:		}
 799:	
]

gemini-3.7-flash

							input: 18509
							output: 27
							thoughts: 45
						

Okay, here's my take on those thoughts, framed as my own mental process, given my expertise:

**Investigating Device Registration and Unregistration Flows**

Right, so I need to dig into the device registration and unregistration process, specifically focusing on what happens when things go sideways, or when a device is deliberately unregistered. My immediate concern is resource management; I need to ensure that any resources associated with the device are cleanly released in these failure scenarios.

Let's start by zeroing in on the cleanup operations. I suspect `msft_release` is involved, and I'll need to check how it's called within these failure paths, or in tear-down routines. Where does it fit into the picture? I'll also want to look for any instances of `idr_destroy`. That's a classic function to clean up resource IDs, so I'll bet it’s involved here. This should give me a good overview of the resource deallocation strategy during both successful and unsuccessful registration/unregistration.

map[Expression:msft_release PathPrefix:net/bluetooth]

map[Output:net/bluetooth/hci_core.c=2706=void hci_release_dev(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-2730-	hci_codec_list_clear(&hdev->local_codecs);
net/bluetooth/hci_core.c:2731:	msft_release(hdev);
net/bluetooth/hci_core.c-2732-	hci_dev_unlock(hdev);
--
net/bluetooth/msft.c=753=void msft_register(struct hci_dev *hdev)
--
net/bluetooth/msft.c-770-
net/bluetooth/msft.c:771:void msft_release(struct hci_dev *hdev)
net/bluetooth/msft.c-772-{
--
net/bluetooth/msft.h=16=void msft_register(struct hci_dev *hdev);
net/bluetooth/msft.h:17:void msft_release(struct hci_dev *hdev);
net/bluetooth/msft.h-18-void msft_do_open(struct hci_dev *hdev);
--
net/bluetooth/msft.h=37=static inline void msft_register(struct hci_dev *hdev) {}
net/bluetooth/msft.h:38:static inline void msft_release(struct hci_dev *hdev) {}
net/bluetooth/msft.h-39-static inline void msft_do_open(struct hci_dev *hdev) {}
]

gemini-3.7-flash

							input: 19192
							output: 39
							thoughts: 31
						

Okay, let's dive into this. Here's my thought process on what I'm about to do:

**Checking `hci_release_dev` and `hci_unregister_dev`**

Alright, I need to get a clear picture of how Bluetooth HCI device management is being handled, particularly during release and unregistration. My gut tells me these functions in `net/bluetooth/hci_core.c`, namely `hci_release_dev` and `hci_unregister_dev`, will be key to understanding the full lifecycle. I want to see exactly how these devices are cleaned up and resources deallocated when a device is no longer needed or is being removed. I expect to find critical interactions with other core Bluetooth data structures and potentially resource management mechanisms. I’ll need to trace the implications of these calls, considering how state transitions and error handling are implemented within them. This should help me better understand the overall system robustness and any potential areas for improvement or vulnerabilities, especially in regards to potential race conditions or resource leaks. Let's see what we can find.

map[File:net/bluetooth/hci_core.c FirstLine:2650 LineCount:100]

map[Contents:2650:	/* Unregister HCI device */
2651:	void hci_unregister_dev(struct hci_dev *hdev)
2652:	{
2653:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2654:	
2655:		mutex_lock(&hdev->unregister_lock);
2656:		hci_dev_set_flag(hdev, HCI_UNREGISTER);
2657:		mutex_unlock(&hdev->unregister_lock);
2658:	
2659:		write_lock(&hci_dev_list_lock);
2660:		list_del(&hdev->list);
2661:		write_unlock(&hci_dev_list_lock);
2662:	
2663:		synchronize_srcu(&hdev->srcu);
2664:		cleanup_srcu_struct(&hdev->srcu);
2665:	
2666:		disable_work_sync(&hdev->rx_work);
2667:		disable_work_sync(&hdev->cmd_work);
2668:		disable_work_sync(&hdev->tx_work);
2669:		disable_work_sync(&hdev->power_on);
2670:		disable_work_sync(&hdev->error_reset);
2671:		disable_delayed_work_sync(&hdev->cmd_timer);
2672:		disable_delayed_work_sync(&hdev->ncmd_timer);
2673:	
2674:		hci_cmd_sync_clear(hdev);
2675:	
2676:		hci_unregister_suspend_notifier(hdev);
2677:	
2678:		hci_dev_do_close(hdev);
2679:	
2680:		if (!test_bit(HCI_INIT, &hdev->flags) &&
2681:		    !hci_dev_test_flag(hdev, HCI_SETUP) &&
2682:		    !hci_dev_test_flag(hdev, HCI_CONFIG)) {
2683:			hci_dev_lock(hdev);
2684:			mgmt_index_removed(hdev);
2685:			hci_dev_unlock(hdev);
2686:		}
2687:	
2688:		/* mgmt_index_removed should take care of emptying the
2689:		 * pending list */
2690:		BUG_ON(!list_empty(&hdev->mgmt_pending));
2691:	
2692:		hci_sock_dev_event(hdev, HCI_DEV_UNREG);
2693:	
2694:		if (hdev->rfkill) {
2695:			rfkill_unregister(hdev->rfkill);
2696:			rfkill_destroy(hdev->rfkill);
2697:		}
2698:	
2699:		device_del(&hdev->dev);
2700:		/* Actual cleanup is deferred until hci_release_dev(). */
2701:		hci_dev_put(hdev);
2702:	}
2703:	EXPORT_SYMBOL(hci_unregister_dev);
2704:	
2705:	/* Release HCI device */
2706:	void hci_release_dev(struct hci_dev *hdev)
2707:	{
2708:		debugfs_remove_recursive(hdev->debugfs);
2709:		kfree_const(hdev->hw_info);
2710:		kfree_const(hdev->fw_info);
2711:	
2712:		destroy_workqueue(hdev->workqueue);
2713:		destroy_workqueue(hdev->req_workqueue);
2714:	
2715:		hci_dev_lock(hdev);
2716:		hci_bdaddr_list_clear(&hdev->reject_list);
2717:		hci_bdaddr_list_clear(&hdev->accept_list);
2718:		hci_uuids_clear(hdev);
2719:		hci_link_keys_clear(hdev);
2720:		hci_smp_ltks_clear(hdev);
2721:		hci_smp_irks_clear(hdev);
2722:		hci_remote_oob_data_clear(hdev);
2723:		hci_adv_instances_clear(hdev);
2724:		hci_adv_monitors_clear(hdev);
2725:		hci_bdaddr_list_clear(&hdev->le_accept_list);
2726:		hci_bdaddr_list_clear(&hdev->le_resolv_list);
2727:		hci_conn_params_clear_all(hdev);
2728:		hci_discovery_filter_clear(hdev);
2729:		hci_blocked_keys_clear(hdev);
2730:		hci_codec_list_clear(&hdev->local_codecs);
2731:		msft_release(hdev);
2732:		hci_dev_unlock(hdev);
2733:	
2734:		ida_destroy(&hdev->unset_handle_ida);
2735:		ida_free(&hci_index_ida, hdev->id);
2736:		kfree_skb(hdev->sent_cmd);
2737:		kfree_skb(hdev->req_skb);
2738:		kfree_skb(hdev->recv_event);
2739:		kfree(hdev);
2740:	}
2741:	EXPORT_SYMBOL(hci_release_dev);
2742:	
2743:	int hci_register_suspend_notifier(struct hci_dev *hdev)
2744:	{
2745:		int ret = 0;
2746:	
2747:		if (!hdev->suspend_notifier.notifier_call &&
2748:		    !hci_test_quirk(hdev, HCI_QUIRK_NO_SUSPEND_NOTIFIER)) {
2749:			hdev->suspend_notifier.notifier_call = hci_suspend_notifier;
]

gemini-3.7-flash

							input: 21158
							output: 29
							thoughts: 309
						

**Investigating Potential Double Initialization**

Okay, so I'm digging into this `hdev->adv_monitors_idr` and I need to make sure this isn't initialized twice. My first thought is to check if `idr_init(&hdev->adv_monitors_idr)` is exclusively called within either `hci_register_dev` or `hci_alloc_dev_priv`. That's the most likely place for this sort of problem to crop up.

Hold on a second, though, I need to understand the lifecycle of `hdev->adv_monitors_idr`. Where is it *actually* initialized and destroyed? A quick search brings me to `hci_adv_monitors_clear(hdev)` which is called from `hci_release_dev`. Looks like it's destroyed there with a `idr_destroy(&hdev->adv_monitors_idr)`. Okay, so at least we know *when* it's torn down.

Right, back to the initialization. I have to make sure `idr_init(&hdev->adv_monitors_idr)` is being called in `hci_register_dev`. This is important, as the initialization is paired with the tear-down.

Hang on... now I'm thinking, why wasn't this initialization done in `hci_alloc_dev_priv`? It seems like this would be a more logical place. I will have to look into this more. I'm going to leverage git blame or history on `adv_monitors_idr`, and also check the code related to `msft_register` and `queue_work(hdev->req_workqueue, &hdev->power_on)` to see if there's any implicit initialization or resource management happening there that I might be missing.

map[CodeRegexp:adv_monitors_idr Count:10]

map[Output:936daee9cf08 Bluetooth: Remove hci_request.{c,h}
7cf5c2978f23 Bluetooth: hci_sync: Refactor remove Adv Monitor
b747a83690c8 Bluetooth: hci_sync: Refactor add Adv Monitor
182ee45da083 Bluetooth: hci_sync: Rework hci_suspend_notifier
e8907f76544f Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3
ce81843be24e Bluetooth: Fix Advertisement Monitor Suspend/Resume
4a37682c6b59 Bluetooth: advmon offload MSFT handle controller reset
66bd095ab5d4 Bluetooth: advmon offload MSFT remove monitor
a2a4dedf88ab Bluetooth: advmon offload MSFT add monitor
c4f1f408168c Bluetooth: Interleave with allowlist scan
]

gemini-3.7-flash

							input: 22134
							output: 25
							thoughts: 42
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating the Implementation History of `idr_init`**

Alright, so I need to dig into the origins or modifications surrounding the `idr_init` function. Specifically, I'm thinking about tracing a couple of commits, `7cf5c2978f23` and `182ee45da083`. I'm guessing one of these will show the initial introduction of this function, or maybe a significant refactor that changed its behavior. I might need to trace them both to see how the code evolved. From there, I'll need to review the commit messages and changesets to grasp the rationale and any context that led to those particular code revisions. The goal is to rapidly understand the historical context surrounding this function, so I can see what influences the current behavior or implementation.

log-in to see details

map[CodeRegexp:msft_register Count:5]

map[Output:]

gemini-3.7-flash

							input: 22427
							output: 34
							thoughts: 11
						

Here's my summary, as though I'm thinking through this process:

**Defining the Path Prefix**

Okay, so we're looking at configuring something, and the key here is to define a `PathPrefix`. The concept is pretty clear: we're establishing a hierarchical route or location for something. The "net/bluetooth" part is critical. This is where the magic happens. By setting `PathPrefix="net/bluetooth"`, I'm creating a specific, well-defined segment for this particular component or configuration. It’s like saying, "Hey, anything related to *network* and *bluetooth* stuff will be found under this directory/URL/whatever structure this system uses." This makes things organized, predictable, and manageable. The implications are far-reaching. It provides a clear way to address and manage a certain set of resources.

map[CodeRegexp:msft_register Count:5 PathPrefix:net/bluetooth]

map[Output:5031ffcc79b8 Bluetooth: Keep MSFT ext info throughout a hci_dev's life cycle
]

gemini-3.7-flash

							input: 22691
							output: 25
							thoughts: 17
						

Okay, here's my interpretation of what's going through my mind when I encounter the commit hash `5031ffcc79b8`:

**Initial Assessment: Diving into the Commit**

Alright, `5031ffcc79b8`. Let's get right into it, I need to understand what this commit did. I'm going to quickly get a sense of the context. First, I want to see if it's a hotfix, a feature addition, or a refactor. A quick `git log -p 5031ffcc79b8` or a look at the commit message and diff is a good starting point to categorize it. Depending on the size of the change I'll know if I need to dig deeper.

If it's large, I might start by identifying the affected modules, and related dependencies. I'll mentally map out the impacted areas of the code base. Are we touching core functionality, or something more isolated? I'll be looking for potential side effects. What edge cases might this introduce, or unintentionally address?

My focus then shifts to the reasoning behind the change. I need to understand *why* this commit was made. Was it a bug fix? An optimization? Or maybe it adds functionality that could impact design? The commit message should be a solid foundation for this analysis, but I can't blindly trust it. I might need to trace the change back to related issues or pull requests to fully understand the rationale.

Finally, I need to evaluate the code quality. Is the code well-written, easy to understand, and maintainable? Are the changes consistent with existing coding conventions? Are there unit tests? Does it appear that the code has been tested in a real environment? I'll be particularly vigilant for potential performance bottlenecks or security vulnerabilities. If I find any red flags, I will want to verify that the fix is sufficient. I might even be prompted to add my own analysis to improve the code.

map[Commit:5031ffcc79b8]

map[Output:commit 5031ffcc79b81776ac8f7f8b1a585aed8818e3d1
Author: Miao-chen Chou <mcchou@chromium.org>
Date:   Thu Sep 9 14:10:23 2021 -0700

    Bluetooth: Keep MSFT ext info throughout a hci_dev's life cycle
    
    This splits the msft_do_{open/close} to msft_do_{open/close} and
    msft_{register/unregister}. With this change it is possible to retain
    the MSFT extension info irrespective of controller power on/off state.
    This helps bluetoothd to report correct 'supported features' of the
    controller to the D-Bus clients event if the controller is off. It also
    re-reads the MSFT info upon every msft_do_open().
    
    The following test steps were performed.
    1. Boot the test device and verify the MSFT support debug log in syslog.
    2. Power off the controller and read the 'supported features', power on
       and read again.
    3. Restart the bluetoothd and verify the 'supported features' value.
    
    Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Reviewed-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Alain Michaud <alainm@chromium.org>
    Signed-off-by: Manish Mandlik <mmandlik@google.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5236faa397fa..beda5dac1658 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3990,6 +3990,7 @@ int hci_register_dev(struct hci_dev *hdev)
 	queue_work(hdev->req_workqueue, &hdev->power_on);
 
 	idr_init(&hdev->adv_monitors_idr);
+	msft_register(hdev);
 
 	return id;
 
@@ -4022,6 +4023,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
 		cancel_work_sync(&hdev->suspend_prepare);
 	}
 
+	msft_unregister(hdev);
+
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index b4bfae41e8a5..21b1787e7893 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -184,28 +184,36 @@ static void reregister_monitor_on_restart(struct hci_dev *hdev, int handle)
 
 void msft_do_open(struct hci_dev *hdev)
 {
-	struct msft_data *msft;
+	struct msft_data *msft = hdev->msft_data;
 
 	if (hdev->msft_opcode == HCI_OP_NOP)
 		return;
 
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT extension not registered");
+		return;
+	}
+
 	bt_dev_dbg(hdev, "Initialize MSFT extension");
 
-	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
-	if (!msft)
-		return;
+	/* Reset existing MSFT data before re-reading */
+	kfree(msft->evt_prefix);
+	msft->evt_prefix = NULL;
+	msft->evt_prefix_len = 0;
+	msft->features = 0;
 
 	if (!read_supported_features(hdev, msft)) {
+		hdev->msft_data = NULL;
 		kfree(msft);
 		return;
 	}
 
-	INIT_LIST_HEAD(&msft->handle_map);
-	hdev->msft_data = msft;
-
 	if (msft_monitor_supported(hdev)) {
 		msft->reregistering = true;
 		msft_set_filter_enable(hdev, true);
+		/* Monitors get removed on power off, so we need to explicitly
+		 * tell the controller to re-monitor.
+		 */
 		reregister_monitor_on_restart(hdev, 0);
 	}
 }
@@ -221,8 +229,9 @@ void msft_do_close(struct hci_dev *hdev)
 
 	bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 
-	hdev->msft_data = NULL;
-
+	/* The controller will silently remove all monitors on power off.
+	 * Therefore, remove handle_data mapping and reset monitor state.
+	 */
 	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 		monitor = idr_find(&hdev->adv_monitors_idr,
 				   handle_data->mgmt_handle);
@@ -233,6 +242,34 @@ void msft_do_close(struct hci_dev *hdev)
 		list_del(&handle_data->list);
 		kfree(handle_data);
 	}
+}
+
+void msft_register(struct hci_dev *hdev)
+{
+	struct msft_data *msft = NULL;
+
+	bt_dev_dbg(hdev, "Register MSFT extension");
+
+	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
+	if (!msft) {
+		bt_dev_err(hdev, "Failed to register MSFT extension");
+		return;
+	}
+
+	INIT_LIST_HEAD(&msft->handle_map);
+	hdev->msft_data = msft;
+}
+
+void msft_unregister(struct hci_dev *hdev)
+{
+	struct msft_data *msft = hdev->msft_data;
+
+	if (!msft)
+		return;
+
+	bt_dev_dbg(hdev, "Unregister MSFT extension");
+
+	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
 	kfree(msft);
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 6e56d94b88d8..8018948c5975 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -13,6 +13,8 @@
 #if IS_ENABLED(CONFIG_BT_MSFTEXT)
 
 bool msft_monitor_supported(struct hci_dev *hdev);
+void msft_register(struct hci_dev *hdev);
+void msft_unregister(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb);
@@ -31,6 +33,8 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 	return false;
 }
 
+static inline void msft_register(struct hci_dev *hdev) {}
+static inline void msft_unregister(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb) {}
]

gemini-3.7-flash

							input: 25247
							output: 33
							thoughts: 112
						

**Analyzing Recent Code Changes**

Okay, let's dissect this commit, `5031ffcc79b8`. Seems like the primary focus was setting up some core initialization and registration. I see `queue_work` is being called for `hdev->power_on`, which is standard practice for asynchronous operations within the kernel. And there's the `idr_init` call for `hdev->adv_monitors_idr`, a common pattern for managing identifiers. But this `msft_register(hdev)` call is the most interesting addition. I need to understand what this is registering; my gut is telling me it's Microsoft-specific.

Now, I want to drill down further. I need to understand how the `filter_lock` was added to `msft_data`. Knowing the context around its introduction is critical. This could be a performance optimization, a synchronization primitive, or possibly related to some security context. Let's dig into the history and find the commit that introduced it. I need to understand the design rationale behind its inclusion.

map[CodeRegexp:filter_lock Count:5 PathPrefix:net/bluetooth]

map[Output:9e14606d8f38 Bluetooth: msft: Extended monitor tracking by address filter
]

gemini-3.7-flash

							input: 25657
							output: 27
							thoughts: 19
						

Okay, let's dive into commit `9e14606d8f38`.

**Analyzing Commit 9e14606d8f38**

Alright, I'm examining commit `9e14606d8f38`. My initial focus is on the diff. What changed? What files were touched? Were there significant code additions, removals, or modifications? I'm immediately looking for any potential architectural shifts or bug fixes implied by the commit message and the delta. Is this a feature implementation, a refactor, a bug fix, or something else entirely? The commit message should give some clues, but I'm not taking anything at face value. I'll read the code with a critical eye, looking for patterns, potential side effects, and adherence to established coding standards. Depending on the size of the change, I might need to consider the context of the related modules and functionality, and perform some brief tests to determine the impacts of this commit. I'm assessing the impact on existing systems, looking for any possible regressions or performance issues that might have emerged. I'll note anything that jumps out as particularly clever, or particularly risky. Finally, I'll consider how this commit fits within the overall project goals and roadmap.

map[Commit:9e14606d8f38]

map[Output:commit 9e14606d8f38ea52a38c27692a9c1513c987a5da
Author: Hilda Wu <hildawu@realtek.com>
Date:   Wed Jun 21 18:00:31 2023 +0800

    Bluetooth: msft: Extended monitor tracking by address filter
    
    Since limited tracking device per condition, this feature is to support
    tracking multiple devices concurrently.
    When a pattern monitor detects the device, this feature issues an address
    monitor for tracking that device. Let pattern monitor can keep monitor
    new devices.
    This feature adds an address filter when receiving a LE monitor device
    event which monitor handle is for a pattern, and the controller started
    monitoring the device. And this feature also has cancelled the monitor
    advertisement from address filters when receiving a LE monitor device
    event when the controller stopped monitoring the device specified by an
    address and monitor handle.
    
    Below is an example to know the feature adds the address filter.
    
    //Add MSFT pattern monitor
    < HCI Command: Vendor (0x3f|0x00f0) plen 14          #142 [hci0] 55.552420
            03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
    > HCI Event: Command Complete (0x0e) plen 6          #143 [hci0] 55.653960
          Vendor (0x3f|0x00f0) ncmd 2
            Status: Success (0x00)
            03 00
    
    //Got event from the pattern monitor
    > HCI Event: Vendor (0xff) plen 18                   #148 [hci0] 58.384953
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            00 01                                            ..
    
    //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
    < HCI Command: Vendor (0x3f|0x00f0) plen 13          #149 [hci0] 58.385067
            03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.
    
    //Report to userspace about found device (ADV Monitor Device Found)
    @ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
            01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
            0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
            c1 03 03 03 12 18                                ......
    
    //Got event from address monitor
    > HCI Event: Vendor (0xff) plen 18                   #152 [hci0] 58.672956
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            01 01
    
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Hilda Wu <hildawu@realtek.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 04399b3c39a0..ddae6524106d 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -1269,6 +1269,10 @@ void btrtl_set_quirks(struct hci_dev *hdev, struct btrtl_device_info *btrtl_dev)
 		if (btrtl_dev->project_id == CHIP_ID_8852C)
 			btrealtek_set_flag(hdev, REALTEK_ALT6_CONTINUOUS_TX_CHIP);
 
+		if (btrtl_dev->project_id == CHIP_ID_8852A ||
+		    btrtl_dev->project_id == CHIP_ID_8852C)
+			set_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks);
+
 		hci_set_aosp_capable(hdev);
 		break;
 	default:
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ab2f8f1817cf..5723405b833e 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -309,6 +309,16 @@ enum {
 	 * to support it.
 	 */
 	HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT,
+
+	/* When this quirk is set, MSFT extension monitor tracking by
+	 * address filter is supported. Since tracking quantity of each
+	 * pattern is limited, this feature supports tracking multiple
+	 * devices concurrently if controller supports multiple
+	 * address filters.
+	 *
+	 * This quirk must be set before hci_register_dev is called.
+	 */
+	HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER,
 };
 
 /* HCI device flags */
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index bf5cee48916c..b80a2162a5c3 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -91,6 +91,33 @@ struct msft_ev_le_monitor_device {
 struct msft_monitor_advertisement_handle_data {
 	__u8  msft_handle;
 	__u16 mgmt_handle;
+	__s8 rssi_high;
+	__s8 rssi_low;
+	__u8 rssi_low_interval;
+	__u8 rssi_sampling_period;
+	__u8 cond_type;
+	struct list_head list;
+};
+
+enum monitor_addr_filter_state {
+	AF_STATE_IDLE,
+	AF_STATE_ADDING,
+	AF_STATE_ADDED,
+	AF_STATE_REMOVING,
+};
+
+#define MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR	0x04
+struct msft_monitor_addr_filter_data {
+	__u8     msft_handle;
+	__u8     pattern_handle; /* address filters pertain to */
+	__u16    mgmt_handle;
+	int      state;
+	__s8     rssi_high;
+	__s8     rssi_low;
+	__u8     rssi_low_interval;
+	__u8     rssi_sampling_period;
+	__u8     addr_type;
+	bdaddr_t bdaddr;
 	struct list_head list;
 };
 
@@ -99,9 +126,12 @@ struct msft_data {
 	__u8  evt_prefix_len;
 	__u8  *evt_prefix;
 	struct list_head handle_map;
+	struct list_head address_filters;
 	__u8 resuming;
 	__u8 suspending;
 	__u8 filter_enabled;
+	/* To synchronize add/remove address filter and monitor device event.*/
+	struct mutex filter_lock;
 };
 
 bool msft_monitor_supported(struct hci_dev *hdev)
@@ -180,6 +210,24 @@ static struct msft_monitor_advertisement_handle_data *msft_find_handle_data
 	return NULL;
 }
 
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_find_address_data
+			(struct hci_dev *hdev, u8 addr_type, bdaddr_t *addr,
+			 u8 pattern_handle)
+{
+	struct msft_monitor_addr_filter_data *entry;
+	struct msft_data *msft = hdev->msft_data;
+
+	list_for_each_entry(entry, &msft->address_filters, list) {
+		if (entry->pattern_handle == pattern_handle &&
+		    addr_type == entry->addr_type &&
+		    !bacmp(addr, &entry->bdaddr))
+			return entry;
+	}
+
+	return NULL;
+}
+
 /* This function requires the caller holds hdev->lock */
 static int msft_monitor_device_del(struct hci_dev *hdev, __u16 mgmt_handle,
 				   bdaddr_t *bdaddr, __u8 addr_type,
@@ -240,6 +288,7 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 
 	handle_data->mgmt_handle = monitor->handle;
 	handle_data->msft_handle = rp->handle;
+	handle_data->cond_type   = MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN;
 	INIT_LIST_HEAD(&handle_data->list);
 	list_add(&handle_data->list, &msft->handle_map);
 
@@ -254,6 +303,70 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 	return status;
 }
 
+/* This function requires the caller holds hci_req_sync_lock */
+static void msft_remove_addr_filters_sync(struct hci_dev *hdev, u8 handle)
+{
+	struct msft_monitor_addr_filter_data *address_filter, *n;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct list_head head;
+	struct sk_buff *skb;
+
+	INIT_LIST_HEAD(&head);
+
+	/* Cancel all corresponding address monitors */
+	mutex_lock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		if (address_filter->pattern_handle != handle)
+			continue;
+
+		list_del(&address_filter->list);
+
+		/* Keep the address filter and let
+		 * msft_add_address_filter_sync() remove and free the address
+		 * filter.
+		 */
+		if (address_filter->state == AF_STATE_ADDING) {
+			address_filter->state = AF_STATE_REMOVING;
+			continue;
+		}
+
+		/* Keep the address filter and let
+		 * msft_cancel_address_filter_sync() remove and free the address
+		 * filter
+		 */
+		if (address_filter->state == AF_STATE_REMOVING)
+			continue;
+
+		list_add_tail(&address_filter->list, &head);
+	}
+
+	mutex_unlock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &head, list) {
+		list_del(&address_filter->list);
+
+		cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+		cp.handle = address_filter->msft_handle;
+
+		skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+				     HCI_CMD_TIMEOUT);
+		if (IS_ERR_OR_NULL(skb)) {
+			kfree(address_filter);
+			continue;
+		}
+
+		kfree_skb(skb);
+
+		bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+			   &address_filter->bdaddr);
+
+		kfree(address_filter);
+	}
+}
+
 static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						   u16 opcode,
 						   struct adv_monitor *monitor,
@@ -263,6 +376,7 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_data *msft = hdev->msft_data;
 	int status = 0;
+	u8 msft_handle;
 
 	rp = (struct msft_rp_le_cancel_monitor_advertisement *)skb->data;
 	if (skb->len < sizeof(*rp)) {
@@ -293,11 +407,17 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						NULL, 0, false);
 		}
 
+		msft_handle = handle_data->msft_handle;
+
 		list_del(&handle_data->list);
 		kfree(handle_data);
-	}
 
-	hci_dev_unlock(hdev);
+		hci_dev_unlock(hdev);
+
+		msft_remove_addr_filters_sync(hdev, msft_handle);
+	} else {
+		hci_dev_unlock(hdev);
+	}
 
 done:
 	return status;
@@ -394,12 +514,14 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 {
 	struct msft_cp_le_monitor_advertisement *cp;
 	struct msft_le_monitor_advertisement_pattern_data *pattern_data;
+	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_le_monitor_advertisement_pattern *pattern;
 	struct adv_pattern *entry;
 	size_t total_size = sizeof(*cp) + sizeof(*pattern_data);
 	ptrdiff_t offset = 0;
 	u8 pattern_count = 0;
 	struct sk_buff *skb;
+	int err;
 
 	if (!msft_monitor_pattern_valid(monitor))
 		return -EINVAL;
@@ -436,16 +558,31 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 
 	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, total_size, cp,
 			     HCI_CMD_TIMEOUT);
-	kfree(cp);
 
 	if (IS_ERR_OR_NULL(skb)) {
-		if (!skb)
-			return -EIO;
-		return PTR_ERR(skb);
+		err = PTR_ERR(skb);
+		goto out_free;
 	}
 
-	return msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
-						monitor, skb);
+	err = msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
+					       monitor, skb);
+	if (err)
+		goto out_free;
+
+	handle_data = msft_find_handle_data(hdev, monitor->handle, true);
+	if (!handle_data) {
+		err = -ENODATA;
+		goto out_free;
+	}
+
+	handle_data->rssi_high	= cp->rssi_high;
+	handle_data->rssi_low	= cp->rssi_low;
+	handle_data->rssi_low_interval	  = cp->rssi_low_interval;
+	handle_data->rssi_sampling_period = cp->rssi_sampling_period;
+
+out_free:
+	kfree(cp);
+	return err;
 }
 
 /* This function requires the caller holds hci_req_sync_lock */
@@ -538,6 +675,7 @@ void msft_do_close(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 	struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
+	struct msft_monitor_addr_filter_data *address_filter, *n;
 	struct adv_monitor *monitor;
 
 	if (!msft)
@@ -559,6 +697,14 @@ void msft_do_close(struct hci_dev *hdev)
 		kfree(handle_data);
 	}
 
+	mutex_lock(&msft->filter_lock);
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	}
+	mutex_unlock(&msft->filter_lock);
+
 	hci_dev_lock(hdev);
 
 	/* Clear any devices that are being monitored and notify device lost */
@@ -568,6 +714,49 @@ void msft_do_close(struct hci_dev *hdev)
 	hci_dev_unlock(hdev);
 }
 
+static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb;
+	int err = 0;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return 0;
+
+	mutex_lock(&msft->filter_lock);
+	list_del(&address_filter->list);
+	mutex_unlock(&msft->filter_lock);
+
+	cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+	cp.handle = address_filter->msft_handle;
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "MSFT: Failed to cancel address (%pMR) filter",
+			   &address_filter->bdaddr);
+		err = EIO;
+		goto done;
+	}
+	kfree_skb(skb);
+
+	bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+		   &address_filter->bdaddr);
+
+done:
+	kfree(address_filter);
+
+	return err;
+}
+
 void msft_register(struct hci_dev *hdev)
 {
 	struct msft_data *msft = NULL;
@@ -581,7 +770,9 @@ void msft_register(struct hci_dev *hdev)
 	}
 
 	INIT_LIST_HEAD(&msft->handle_map);
+	INIT_LIST_HEAD(&msft->address_filters);
 	hdev->msft_data = msft;
+	mutex_init(&msft->filter_lock);
 }
 
 void msft_unregister(struct hci_dev *hdev)
@@ -596,6 +787,7 @@ void msft_unregister(struct hci_dev *hdev)
 	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
+	mutex_destroy(&msft->filter_lock);
 	kfree(msft);
 }
 
@@ -645,11 +837,149 @@ static void *msft_skb_pull(struct hci_dev *hdev, struct sk_buff *skb,
 	return data;
 }
 
+static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_rp_le_monitor_advertisement *rp;
+	struct msft_cp_le_monitor_advertisement *cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb = NULL;
+	bool remove = false;
+	size_t size;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return -ENODEV;
+
+	/* We are safe to use the address filter from now on.
+	 * msft_monitor_device_evt() wouldn't delete this filter because it's
+	 * not been added by now.
+	 * And all other functions that requiring hci_req_sync_lock wouldn't
+	 * touch this filter before this func completes because it's protected
+	 * by hci_req_sync_lock.
+	 */
+
+	if (address_filter->state == AF_STATE_REMOVING) {
+		mutex_lock(&msft->filter_lock);
+		list_del(&address_filter->list);
+		mutex_unlock(&msft->filter_lock);
+		kfree(address_filter);
+		return 0;
+	}
+
+	size = sizeof(*cp) +
+	       sizeof(address_filter->addr_type) +
+	       sizeof(address_filter->bdaddr);
+	cp = kzalloc(size, GFP_KERNEL);
+	if (!cp) {
+		bt_dev_err(hdev, "MSFT: Alloc cmd param err");
+		remove = true;
+		goto done;
+	}
+	cp->sub_opcode           = MSFT_OP_LE_MONITOR_ADVERTISEMENT;
+	cp->rssi_high		 = address_filter->rssi_high;
+	cp->rssi_low		 = address_filter->rssi_low;
+	cp->rssi_low_interval    = address_filter->rssi_low_interval;
+	cp->rssi_sampling_period = address_filter->rssi_sampling_period;
+	cp->cond_type            = MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR;
+	cp->data[0]              = address_filter->addr_type;
+	memcpy(&cp->data[1], &address_filter->bdaddr,
+	       sizeof(address_filter->bdaddr));
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, size, cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "Failed to enable address %pMR filter",
+			   &address_filter->bdaddr);
+		skb = NULL;
+		remove = true;
+		goto done;
+	}
+
+	rp = skb_pull_data(skb, sizeof(*rp));
+	if (!rp || rp->sub_opcode != MSFT_OP_LE_MONITOR_ADVERTISEMENT ||
+	    rp->status)
+		remove = true;
+
+done:
+	mutex_lock(&msft->filter_lock);
+
+	if (remove) {
+		bt_dev_warn(hdev, "MSFT: Remove address (%pMR) filter",
+			    &address_filter->bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	} else {
+		address_filter->state = AF_STATE_ADDED;
+		address_filter->msft_handle = rp->handle;
+		bt_dev_dbg(hdev, "MSFT: Address %pMR filter enabled",
+			   &address_filter->bdaddr);
+	}
+	mutex_unlock(&msft->filter_lock);
+
+	kfree_skb(skb);
+
+	return 0;
+}
+
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_add_address_filter
+		(struct hci_dev *hdev, u8 addr_type, bdaddr_t *bdaddr,
+		 struct msft_monitor_advertisement_handle_data *handle_data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = NULL;
+	struct msft_data *msft = hdev->msft_data;
+	int err;
+
+	address_filter = kzalloc(sizeof(*address_filter), GFP_KERNEL);
+	if (!address_filter)
+		return NULL;
+
+	address_filter->state             = AF_STATE_ADDING;
+	address_filter->msft_handle       = 0xff;
+	address_filter->pattern_handle    = handle_data->msft_handle;
+	address_filter->mgmt_handle       = handle_data->mgmt_handle;
+	address_filter->rssi_high         = handle_data->rssi_high;
+	address_filter->rssi_low          = handle_data->rssi_low;
+	address_filter->rssi_low_interval = handle_data->rssi_low_interval;
+	address_filter->rssi_sampling_period = handle_data->rssi_sampling_period;
+	address_filter->addr_type            = addr_type;
+	bacpy(&address_filter->bdaddr, bdaddr);
+
+	/* With the above AF_STATE_ADDING, duplicated address filter can be
+	 * avoided when receiving monitor device event (found/lost) frequently
+	 * for the same device.
+	 */
+	list_add_tail(&address_filter->list, &msft->address_filters);
+
+	err = hci_cmd_sync_queue(hdev, msft_add_address_filter_sync,
+				 address_filter, NULL);
+	if (err < 0) {
+		bt_dev_err(hdev, "MSFT: Add address %pMR filter err", bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+		return NULL;
+	}
+
+	bt_dev_dbg(hdev, "MSFT: Add device %pMR address filter",
+		   &address_filter->bdaddr);
+
+	return address_filter;
+}
+
 /* This function requires the caller holds hdev->lock */
 static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 {
+	struct msft_monitor_addr_filter_data *n, *address_filter = NULL;
 	struct msft_ev_le_monitor_device *ev;
 	struct msft_monitor_advertisement_handle_data *handle_data;
+	struct msft_data *msft = hdev->msft_data;
+	u16 mgmt_handle = 0xffff;
 	u8 addr_type;
 
 	ev = msft_skb_pull(hdev, skb, MSFT_EV_LE_MONITOR_DEVICE, sizeof(*ev));
@@ -662,9 +992,53 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		   ev->monitor_state, &ev->bdaddr);
 
 	handle_data = msft_find_handle_data(hdev, ev->monitor_handle, false);
-	if (!handle_data)
+
+	if (!test_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks)) {
+		if (!handle_data)
+			return;
+		mgmt_handle = handle_data->mgmt_handle;
+		goto report_state;
+	}
+
+	if (handle_data) {
+		/* Don't report any device found/lost event from pattern
+		 * monitors. Pattern monitor always has its address filters for
+		 * tracking devices.
+		 */
+
+		address_filter = msft_find_address_data(hdev, ev->addr_type,
+							&ev->bdaddr,
+							handle_data->msft_handle);
+		if (address_filter)
+			return;
+
+		if (ev->monitor_state && handle_data->cond_type ==
+				MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN)
+			msft_add_address_filter(hdev, ev->addr_type,
+						&ev->bdaddr, handle_data);
+
 		return;
+	}
 
+	/* This device event is not from pattern monitor.
+	 * Report it if there is a corresponding address_filter for it.
+	 */
+	list_for_each_entry(n, &msft->address_filters, list) {
+		if (n->state == AF_STATE_ADDED &&
+		    n->msft_handle == ev->monitor_handle) {
+			mgmt_handle = n->mgmt_handle;
+			address_filter = n;
+			break;
+		}
+	}
+
+	if (!address_filter) {
+		bt_dev_warn(hdev, "MSFT: Unexpected device event %pMR, %u, %u",
+			    &ev->bdaddr, ev->monitor_handle, ev->monitor_state);
+		return;
+	}
+
+report_state:
 	switch (ev->addr_type) {
 	case ADDR_LE_DEV_PUBLIC:
 		addr_type = BDADDR_LE_PUBLIC;
@@ -681,12 +1055,18 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		return;
 	}
 
-	if (ev->monitor_state)
-		msft_device_found(hdev, &ev->bdaddr, addr_type,
-				  handle_data->mgmt_handle);
-	else
-		msft_device_lost(hdev, &ev->bdaddr, addr_type,
-				 handle_data->mgmt_handle);
+	if (ev->monitor_state) {
+		msft_device_found(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	} else {
+		if (address_filter && address_filter->state == AF_STATE_ADDED) {
+			address_filter->state = AF_STATE_REMOVING;
+			hci_cmd_sync_queue(hdev,
+					   msft_cancel_address_filter_sync,
+					   address_filter,
+					   NULL);
+		}
+		msft_device_lost(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	}
 }
 
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
@@ -724,7 +1104,9 @@ void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
 
 	switch (*evt) {
 	case MSFT_EV_LE_MONITOR_DEVICE:
+		mutex_lock(&msft->filter_lock);
 		msft_monitor_device_evt(hdev, skb);
+		mutex_unlock(&msft->filter_lock);
 		break;
 
 	default:
]

gemini-3.7-flash

							input: 34380
							output: 35
							thoughts: 927
						

**Analyzing Bluetooth Device Registration and Initialization**

Okay, let's break this down. I'm looking at the initialization sequence of a Bluetooth device (`hci_dev`) during registration (`hci_register_dev`) and I've spotted a potential race condition. Specifically, the order of operations in `hci_register_dev` is suspect. It starts with a series of calls: `hci_sock_dev_event`, `hci_dev_hold`, `hci_register_suspend_notifier`, `queue_work`, `idr_init`, and `msft_register`.

The problem I see is this: the `power_on` workqueue is queued *before* the `adv_monitors_idr` and `msft` data are initialized.  `hci_power_on` could be triggered before those are initialized, and if it's running when the device is still in an unconfigured state, it calls `hci_dev_do_close`. `hci_dev_do_close` then goes down the call stack to eventually invoke `msft_do_close(hdev)`.

Within `msft_do_close`, several key data structures are accessed: `hdev->msft_data`, `hdev->adv_monitors_idr`, `msft->handle_map`, `msft->address_filters`, and `msft->filter_lock`. If `msft_do_close` runs *before* these are properly initialized, there's a serious problem!

Specifically, `msft_register` first allocates `msft` and sets `hdev->msft_data = msft`. *Then* it initializes the `handle_map` and `address_filters`. *Finally*, it calls `mutex_init(&msft->filter_lock);`. If `msft_do_close` runs before `mutex_init`, there's a call to `mutex_lock` on an uninitialized mutex, which is a big no-no. We're looking at a crash.

To address this, the fix is straightforward: reorder the calls in `hci_register_dev` to ensure initialization *before* queuing `power_on`. So, the correct order should be `idr_init`, `msft_register`, and *then* `queue_work`. And make sure `mutex_init` occurs *before* `hdev->msft_data = msft;`!

Now, I need to be absolutely certain this is the only potential issue. I will go through both `net/bluetooth/msft.c` and `net/bluetooth/hci_core.c`, methodically, to make sure there are no other places where there's a similar exposure of uninitialized data or improper queuing. I'll meticulously read the code of `msft.c`. I need to ensure that I haven't missed something else that might trigger this, or a related, issue.

map[File:net/bluetooth/msft.c FirstLine:1 LineCount:100]

map[Contents:   1:	// SPDX-License-Identifier: GPL-2.0-only
   2:	/*
   3:	 * Copyright (C) 2020 Google Corporation
   4:	 */
   5:	
   6:	#include <net/bluetooth/bluetooth.h>
   7:	#include <net/bluetooth/hci_core.h>
   8:	#include <net/bluetooth/mgmt.h>
   9:	
  10:	#include "mgmt_util.h"
  11:	#include "msft.h"
  12:	
  13:	#define MSFT_RSSI_THRESHOLD_VALUE_MIN		-127
  14:	#define MSFT_RSSI_THRESHOLD_VALUE_MAX		20
  15:	#define MSFT_RSSI_LOW_TIMEOUT_MAX		0x3C
  16:	
  17:	#define MSFT_OP_READ_SUPPORTED_FEATURES		0x00
  18:	struct msft_cp_read_supported_features {
  19:		__u8   sub_opcode;
  20:	} __packed;
  21:	
  22:	struct msft_rp_read_supported_features {
  23:		__u8   status;
  24:		__u8   sub_opcode;
  25:		__le64 features;
  26:		__u8   evt_prefix_len;
  27:		__u8   evt_prefix[];
  28:	} __packed;
  29:	
  30:	#define MSFT_OP_LE_MONITOR_ADVERTISEMENT	0x03
  31:	#define MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN	0x01
  32:	struct msft_le_monitor_advertisement_pattern {
  33:		__u8 length;
  34:		__u8 data_type;
  35:		__u8 start_byte;
  36:		__u8 pattern[];
  37:	};
  38:	
  39:	struct msft_le_monitor_advertisement_pattern_data {
  40:		__u8 count;
  41:		__u8 data[];
  42:	};
  43:	
  44:	struct msft_cp_le_monitor_advertisement {
  45:		__u8 sub_opcode;
  46:		__s8 rssi_high;
  47:		__s8 rssi_low;
  48:		__u8 rssi_low_interval;
  49:		__u8 rssi_sampling_period;
  50:		__u8 cond_type;
  51:		__u8 data[];
  52:	} __packed;
  53:	
  54:	struct msft_rp_le_monitor_advertisement {
  55:		__u8 status;
  56:		__u8 sub_opcode;
  57:		__u8 handle;
  58:	} __packed;
  59:	
  60:	#define MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT	0x04
  61:	struct msft_cp_le_cancel_monitor_advertisement {
  62:		__u8 sub_opcode;
  63:		__u8 handle;
  64:	} __packed;
  65:	
  66:	struct msft_rp_le_cancel_monitor_advertisement {
  67:		__u8 status;
  68:		__u8 sub_opcode;
  69:	} __packed;
  70:	
  71:	#define MSFT_OP_LE_SET_ADVERTISEMENT_FILTER_ENABLE	0x05
  72:	struct msft_cp_le_set_advertisement_filter_enable {
  73:		__u8 sub_opcode;
  74:		__u8 enable;
  75:	} __packed;
  76:	
  77:	struct msft_rp_le_set_advertisement_filter_enable {
  78:		__u8 status;
  79:		__u8 sub_opcode;
  80:	} __packed;
  81:	
  82:	#define MSFT_EV_LE_MONITOR_DEVICE	0x02
  83:	struct msft_ev_le_monitor_device {
  84:		__u8     addr_type;
  85:		bdaddr_t bdaddr;
  86:		__u8     monitor_handle;
  87:		__u8     monitor_state;
  88:	} __packed;
  89:	
  90:	struct msft_monitor_advertisement_handle_data {
  91:		__u8  msft_handle;
  92:		__u16 mgmt_handle;
  93:		__s8 rssi_high;
  94:		__s8 rssi_low;
  95:		__u8 rssi_low_interval;
  96:		__u8 rssi_sampling_period;
  97:		__u8 cond_type;
  98:		struct list_head list;
  99:	};
 100:	
]

gemini-3.7-flash

							input: 37330
							output: 37
							thoughts: 15
						

Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:

**Diving Back into `net/bluetooth/msft.c`**

Okay, time to get back to it. Back into the depths of `net/bluetooth/msft.c`. I'm going to start up where I last left off. I need to refresh my memory on what I was analyzing. It was probably related to the HCi events or possibly how it was dealing with the driver and device specific initialization routines for the MSFT stack.

I expect to see the usual suspects: the register map defines, the interrupt handling logic, and the various `ioctl` handlers if it's got any. I'm hoping to see some of the debugging messages I had enabled last week. I am going to have to work out again what the flow of control is. Then hopefully I can identify exactly where the bottleneck is.

map[File:net/bluetooth/msft.c FirstLine:600 LineCount:100]

map[Contents: 600:			handle++;
 601:		}
 602:	
 603:		/* All monitors have been reregistered */
 604:		msft->resuming = false;
 605:	}
 606:	
 607:	/* This function requires the caller holds hci_req_sync_lock */
 608:	int msft_resume_sync(struct hci_dev *hdev)
 609:	{
 610:		struct msft_data *msft = hdev->msft_data;
 611:	
 612:		if (!msft || !msft_monitor_supported(hdev))
 613:			return 0;
 614:	
 615:		hci_dev_lock(hdev);
 616:	
 617:		/* Clear already tracked devices on resume. Once the monitors are
 618:		 * reregistered, devices in range will be found again after resume.
 619:		 */
 620:		hdev->advmon_pend_notify = false;
 621:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 622:	
 623:		hci_dev_unlock(hdev);
 624:	
 625:		reregister_monitor(hdev);
 626:	
 627:		return 0;
 628:	}
 629:	
 630:	/* This function requires the caller holds hci_req_sync_lock */
 631:	void msft_do_open(struct hci_dev *hdev)
 632:	{
 633:		struct msft_data *msft = hdev->msft_data;
 634:	
 635:		if (hdev->msft_opcode == HCI_OP_NOP)
 636:			return;
 637:	
 638:		if (!msft) {
 639:			bt_dev_err(hdev, "MSFT extension not registered");
 640:			return;
 641:		}
 642:	
 643:		bt_dev_dbg(hdev, "Initialize MSFT extension");
 644:	
 645:		/* Reset existing MSFT data before re-reading */
 646:		kfree(msft->evt_prefix);
 647:		msft->evt_prefix = NULL;
 648:		msft->evt_prefix_len = 0;
 649:		msft->features = 0;
 650:	
 651:		if (!read_supported_features(hdev, msft)) {
 652:			hdev->msft_data = NULL;
 653:			kfree(msft);
 654:			return;
 655:		}
 656:	
 657:		if (msft_monitor_supported(hdev)) {
 658:			msft->resuming = true;
 659:			msft_set_filter_enable(hdev, true);
 660:			/* Monitors get removed on power off, so we need to explicitly
 661:			 * tell the controller to re-monitor.
 662:			 */
 663:			reregister_monitor(hdev);
 664:		}
 665:	}
 666:	
 667:	void msft_do_close(struct hci_dev *hdev)
 668:	{
 669:		struct msft_data *msft = hdev->msft_data;
 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
]

gemini-3.7-flash

							input: 39037
							output: 26
							thoughts: 169
						

**Analyzing a Potential Memory Leak**

Okay, let's break this down. I'm looking at `msft_do_open` here. The key part is that initial `if` statement. If `read_supported_features(hdev, msft)` fails, it's setting `hdev->msft_data = NULL;` and then `kfree(msft);`. The main question I have is, does that free operation properly handle everything allocated within `msft`? Does it destroy `msft->filter_lock` correctly?

The problem description mentioned commit `10f9f426ac6e`. That's a good starting point. I need to examine that specific commit to see if it provides any insight into the memory management, particularly around this `msft` structure and its associated `filter_lock`. Checking that commit will probably give me a better understanding.

map[Commit:10f9f426ac6e]

map[Output:commit 10f9f426ac6e752c8d87bf4346930ba347aaabac
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Tue Apr 30 12:20:51 2024 -0400

    Bluetooth: msft: fix slab-use-after-free in msft_do_close()
    
    Tying the msft->data lifetime to hdev by freeing it in
    hci_release_dev() to fix the following case:
    
    [use]
    msft_do_close()
      msft = hdev->msft_data;
      if (!msft)                      ...(1) <- passed.
        return;
      mutex_lock(&msft->filter_lock); ...(4) <- used after freed.
    
    [free]
    msft_unregister()
      msft = hdev->msft_data;
      hdev->msft_data = NULL;         ...(2)
      kfree(msft);                    ...(3) <- msft is freed.
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in __mutex_lock_common
    kernel/locking/mutex.c:587 [inline]
    BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
    kernel/locking/mutex.c:752
    Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309
    
    Fixes: bf6a4e30ffbd ("Bluetooth: disable advertisement filters during suspend")
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a7028d38c1f5..bc5086423ab8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2768,8 +2768,6 @@ void hci_unregister_dev(struct hci_dev *hdev)
 
 	hci_unregister_suspend_notifier(hdev);
 
-	msft_unregister(hdev);
-
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
@@ -2823,6 +2821,7 @@ void hci_release_dev(struct hci_dev *hdev)
 	hci_discovery_filter_clear(hdev);
 	hci_blocked_keys_clear(hdev);
 	hci_codec_list_clear(&hdev->local_codecs);
+	msft_release(hdev);
 	hci_dev_unlock(hdev);
 
 	ida_destroy(&hdev->unset_handle_ida);
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 9612c5d1b13f..d039683d3bdd 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -769,7 +769,7 @@ void msft_register(struct hci_dev *hdev)
 	mutex_init(&msft->filter_lock);
 }
 
-void msft_unregister(struct hci_dev *hdev)
+void msft_release(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 2a63205b377b..fe538e9c91c0 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -14,7 +14,7 @@
 
 bool msft_monitor_supported(struct hci_dev *hdev);
 void msft_register(struct hci_dev *hdev);
-void msft_unregister(struct hci_dev *hdev);
+void msft_release(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb);
@@ -35,7 +35,7 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 }
 
 static inline void msft_register(struct hci_dev *hdev) {}
-static inline void msft_unregister(struct hci_dev *hdev) {}
+static inline void msft_release(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, void *data,
]

gemini-3.7-flash

							input: 40765
							output: 36
							thoughts: 62
						

**Investigating `msft_do_open` in Bluetooth**

Okay, let's dive into this. I need to take a look at `msft_do_open` within the `net/bluetooth/msft.c` file. Right, that seems like the logical starting point for understanding this particular issue. But wait... what's the control flow here? I need to consider all the possible scenarios, so let's check what happens if `read_supported_features` returns `false`. That could completely change the execution path. Therefore, before proceeding with the examination of `msft_do_open`, I need to scrutinize the `read_supported_features` function itself. I'll need to go directly to its implementation, also in `net/bluetooth/msft.c`, to understand its behavior and potential failure modes. That's the key to understanding the full context here.

map[File:net/bluetooth/msft.c FirstLine:630 LineCount:40]

map[Contents: 630:	/* This function requires the caller holds hci_req_sync_lock */
 631:	void msft_do_open(struct hci_dev *hdev)
 632:	{
 633:		struct msft_data *msft = hdev->msft_data;
 634:	
 635:		if (hdev->msft_opcode == HCI_OP_NOP)
 636:			return;
 637:	
 638:		if (!msft) {
 639:			bt_dev_err(hdev, "MSFT extension not registered");
 640:			return;
 641:		}
 642:	
 643:		bt_dev_dbg(hdev, "Initialize MSFT extension");
 644:	
 645:		/* Reset existing MSFT data before re-reading */
 646:		kfree(msft->evt_prefix);
 647:		msft->evt_prefix = NULL;
 648:		msft->evt_prefix_len = 0;
 649:		msft->features = 0;
 650:	
 651:		if (!read_supported_features(hdev, msft)) {
 652:			hdev->msft_data = NULL;
 653:			kfree(msft);
 654:			return;
 655:		}
 656:	
 657:		if (msft_monitor_supported(hdev)) {
 658:			msft->resuming = true;
 659:			msft_set_filter_enable(hdev, true);
 660:			/* Monitors get removed on power off, so we need to explicitly
 661:			 * tell the controller to re-monitor.
 662:			 */
 663:			reregister_monitor(hdev);
 664:		}
 665:	}
 666:	
 667:	void msft_do_close(struct hci_dev *hdev)
 668:	{
 669:		struct msft_data *msft = hdev->msft_data;
]

gemini-3.7-flash

							input: 41642
							output: 36
							thoughts: 11
						

Okay, here's my attempt at summarizing the thought process, speaking as if they are my own, keeping in mind the user is an expert:

**Investigating Feature Support**

Alright, let's dive in. I need to get a handle on the supported features, so my first move is to verify the `read_supported_features` method. That's the logical starting point. I want to see if this function is actually returning the information I expect, or if there's any funny business going on there. It's the lynchpin, the gateway to understanding what functionality I can rely on. I need to make sure this function behaves as documented and expected - any deviation and that's going to throw a wrench in the entire operation. So let's see what's actually returned.

map[File:net/bluetooth/msft.c FirstLine:140 LineCount:50]

map[Contents: 140:	
 141:	static bool read_supported_features(struct hci_dev *hdev,
 142:					    struct msft_data *msft)
 143:	{
 144:		struct msft_cp_read_supported_features cp;
 145:		struct msft_rp_read_supported_features *rp;
 146:		struct sk_buff *skb;
 147:	
 148:		cp.sub_opcode = MSFT_OP_READ_SUPPORTED_FEATURES;
 149:	
 150:		skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
 151:				     HCI_CMD_TIMEOUT);
 152:		if (IS_ERR(skb)) {
 153:			bt_dev_err(hdev, "Failed to read MSFT supported features (%ld)",
 154:				   PTR_ERR(skb));
 155:			return false;
 156:		}
 157:	
 158:		if (skb->len < sizeof(*rp)) {
 159:			bt_dev_err(hdev, "MSFT supported features length mismatch");
 160:			goto failed;
 161:		}
 162:	
 163:		rp = (struct msft_rp_read_supported_features *)skb->data;
 164:	
 165:		if (rp->sub_opcode != MSFT_OP_READ_SUPPORTED_FEATURES)
 166:			goto failed;
 167:	
 168:		if (rp->evt_prefix_len > 0) {
 169:			msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len,
 170:						   GFP_KERNEL);
 171:			if (!msft->evt_prefix)
 172:				goto failed;
 173:		}
 174:	
 175:		msft->evt_prefix_len = rp->evt_prefix_len;
 176:		msft->features = __le64_to_cpu(rp->features);
 177:	
 178:		if (msft->features & MSFT_FEATURE_MASK_CURVE_VALIDITY)
 179:			hdev->msft_curve_validity = true;
 180:	
 181:		kfree_skb(skb);
 182:		return true;
 183:	
 184:	failed:
 185:		kfree_skb(skb);
 186:		return false;
 187:	}
 188:	
 189:	/* is_mgmt = true matches the handle exposed to userspace via mgmt.
]

gemini-3.7-flash

							input: 42624
							output: 38
							thoughts: 2097
						

**Analyzing a Potential Race Condition in Bluetooth Driver Initialization**

Okay, so I'm looking at this code and immediately I see a potential race condition. Specifically, I'm focusing on the `msft_release` and `msft_do_open` functions related to the MSFT extension within the Bluetooth driver. The issue is, `msft_release` does a `mutex_destroy` on the `filter_lock` field within the `msft_data` struct. Now, `msft_do_open` might free `msft` before that, especially if `read_supported_features` fails, creating a double-free scenario. The `msft_do_close` function does a check for `if (!msft) return;` but the timing is very important.

Now, let's zoom in on the specific bug and proposed fix from the user prompt. The crash occurs when `msft_do_close()` is called from `hci_dev_close_sync()` during power-on, specifically after a call to `queue_work(hdev->req_workqueue, &hdev->power_on)`. This work queue is where the issue lies: The `hci_power_on` work can execute concurrently with the `msft_register` function, causing a race.

Within `hci_register_dev()`, these lines are of interest:

```c
	idr_init(&hdev->adv_monitors_idr);
	msft_register(hdev);
	queue_work(hdev->req_workqueue, &hdev->power_on);
```

The problem is the `queue_work` call. It's happening *after* both `idr_init` and `msft_register`, but `hci_power_on` could be executing immediately. Inside `hci_power_on`, if `HCI_UNCONFIGURED` is set, `hci_dev_do_close` is called which, in turn, calls `msft_do_close`.

Meanwhile, `msft_register` is running concurrently. Here, the `msft_data` is initialized, assigned and mutexes are created.
```c
void msft_register(struct hci_dev *hdev)
{
	struct msft_data *msft = NULL;

	bt_dev_dbg(hdev, "Register MSFT extension");

	msft = kzalloc_obj(*msft);
	if (!msft) {
		bt_dev_err(hdev, "Failed to register MSFT extension");
		return;
	}

	INIT_LIST_HEAD(&msft->handle_map);
	INIT_LIST_HEAD(&msft->address_filters);
	hdev->msft_data = msft;
	mutex_init(&msft->filter_lock);
}
```

So, the critical timing issue is:

1.  We *must* ensure that `idr_init(&hdev->adv_monitors_idr)` and `msft_register(hdev)` happen *before* the `queue_work(hdev->req_workqueue, &hdev->power_on)` call. This is to avoid `msft` being used before it is fully initialized.
2.  Within `msft_register()`, `hdev->msft_data = msft;` *must* be assigned *after* all the initialization of the `msft` struct is complete. This includes the `INIT_LIST_HEAD` calls and `mutex_init`.

This means the current ordering of operations is not thread-safe.

Now, let's re-examine `hci_register_dev` more broadly to look for similar potential issues, especially around registrations or initializations that might be done before work queue scheduling.

Here, I'm paying close attention to the order of operations within `hci_register_dev`. Anything that happens *before* a work queue is scheduled and could be accessed by that work queue is a potential trouble spot.

Alright, the `err_wqueue` path is interesting as it indicates what happens if `device_add` fails. The calls to `idr_init` and `msft_register` are after `device_add`, so that's good. In the error path, the `idr` is not cleaned up.
I am also checking `hci_alloc_dev_priv` to ensure no related structs are initialized there.

map[File:net/bluetooth/hci_core.c FirstLine:2460 LineCount:50]

map[Contents:2460:		hdev->le_max_key_size = SMP_MAX_ENC_KEY_SIZE;
2461:		hdev->le_min_key_size = SMP_MIN_ENC_KEY_SIZE;
2462:		hdev->le_tx_def_phys = HCI_LE_SET_PHY_1M;
2463:		hdev->le_rx_def_phys = HCI_LE_SET_PHY_1M;
2464:		hdev->le_num_of_adv_sets = HCI_MAX_ADV_INSTANCES;
2465:		hdev->def_multi_adv_rotation_duration = HCI_DEFAULT_ADV_DURATION;
2466:		hdev->def_le_autoconnect_timeout = HCI_LE_CONN_TIMEOUT;
2467:		hdev->min_le_tx_power = HCI_TX_POWER_INVALID;
2468:		hdev->max_le_tx_power = HCI_TX_POWER_INVALID;
2469:	
2470:		hdev->rpa_timeout = HCI_DEFAULT_RPA_TIMEOUT;
2471:		hdev->discov_interleaved_timeout = DISCOV_INTERLEAVED_TIMEOUT;
2472:		hdev->conn_info_min_age = DEFAULT_CONN_INFO_MIN_AGE;
2473:		hdev->conn_info_max_age = DEFAULT_CONN_INFO_MAX_AGE;
2474:		hdev->auth_payload_timeout = DEFAULT_AUTH_PAYLOAD_TIMEOUT;
2475:		hdev->min_enc_key_size = HCI_MIN_ENC_KEY_SIZE;
2476:	
2477:		/* default 1.28 sec page scan */
2478:		hdev->def_page_scan_type = PAGE_SCAN_TYPE_STANDARD;
2479:		hdev->def_page_scan_int = 0x0800;
2480:		hdev->def_page_scan_window = 0x0012;
2481:	
2482:		mutex_init(&hdev->lock);
2483:		mutex_init(&hdev->req_lock);
2484:		mutex_init(&hdev->mgmt_pending_lock);
2485:	
2486:		ida_init(&hdev->unset_handle_ida);
2487:	
2488:		INIT_LIST_HEAD(&hdev->mesh_pending);
2489:		INIT_LIST_HEAD(&hdev->mgmt_pending);
2490:		INIT_LIST_HEAD(&hdev->reject_list);
2491:		INIT_LIST_HEAD(&hdev->accept_list);
2492:		INIT_LIST_HEAD(&hdev->uuids);
2493:		INIT_LIST_HEAD(&hdev->link_keys);
2494:		INIT_LIST_HEAD(&hdev->long_term_keys);
2495:		INIT_LIST_HEAD(&hdev->identity_resolving_keys);
2496:		INIT_LIST_HEAD(&hdev->remote_oob_data);
2497:		INIT_LIST_HEAD(&hdev->le_accept_list);
2498:		INIT_LIST_HEAD(&hdev->le_resolv_list);
2499:		INIT_LIST_HEAD(&hdev->le_conn_params);
2500:		INIT_LIST_HEAD(&hdev->pend_le_conns);
2501:		INIT_LIST_HEAD(&hdev->pend_le_reports);
2502:		INIT_LIST_HEAD(&hdev->conn_hash.list);
2503:		INIT_LIST_HEAD(&hdev->adv_instances);
2504:		INIT_LIST_HEAD(&hdev->blocked_keys);
2505:		INIT_LIST_HEAD(&hdev->monitored_devices);
2506:	
2507:		INIT_LIST_HEAD(&hdev->local_codecs);
2508:		INIT_WORK(&hdev->rx_work, hci_rx_work);
2509:		INIT_WORK(&hdev->cmd_work, hci_cmd_work);
]

gemini-3.7-flash

							input: 46826
							output: 26
							thoughts: 71
						

**Investigating Potential Bluetooth Concurrency Issues**

Okay, let's dive in. I need to make sure I've got a comprehensive picture of potential concurrency problems within the Bluetooth networking code. My immediate concern is the initialization of mutexes and any associated memory allocation. First things first: I'm going to scan the `net/bluetooth/` directory meticulously. I'll need to check for instances of `kzalloc_obj`, `kzalloc`, and `mutex_init`. My focus is to identify *where* these are being called in relation to each other, to see if an object is being allocated, and then the mutex associated with it is initialized, or if there's any funny business with pointers being assigned before mutex initialization or list initialization. Any of those could be a red flag. So, let's start with a thorough search for `mutex_init` in that specific directory. I need to understand the lifecycle of these mutexes and the data they protect.

map[Expression:mutex_init PathPrefix:net/bluetooth]

map[Output:net/bluetooth/hci_core.c=2398=struct hci_dev *hci_alloc_dev_priv(int sizeof_priv)
--
net/bluetooth/hci_core.c-2481-
net/bluetooth/hci_core.c:2482:	mutex_init(&hdev->lock);
net/bluetooth/hci_core.c:2483:	mutex_init(&hdev->req_lock);
net/bluetooth/hci_core.c:2484:	mutex_init(&hdev->mgmt_pending_lock);
net/bluetooth/hci_core.c-2485-
--
net/bluetooth/hci_sync.c=626=void hci_cmd_sync_init(struct hci_dev *hdev)
--
net/bluetooth/hci_sync.c-629-	INIT_LIST_HEAD(&hdev->cmd_sync_work_list);
net/bluetooth/hci_sync.c:630:	mutex_init(&hdev->cmd_sync_work_lock);
net/bluetooth/hci_sync.c:631:	mutex_init(&hdev->unregister_lock);
net/bluetooth/hci_sync.c-632-
--
net/bluetooth/hidp/core.c=926=static int hidp_session_new(struct hidp_session **out, const bdaddr_t *bdaddr,
--
net/bluetooth/hidp/core.c-969-	/* session data */
net/bluetooth/hidp/core.c:970:	mutex_init(&session->report_mutex);
net/bluetooth/hidp/core.c-971-	init_waitqueue_head(&session->report_queue);
--
net/bluetooth/l2cap_core.c=443=struct l2cap_chan *l2cap_chan_create(void)
--
net/bluetooth/l2cap_core.c-452-	skb_queue_head_init(&chan->srej_q);
net/bluetooth/l2cap_core.c:453:	mutex_init(&chan->lock);
net/bluetooth/l2cap_core.c-454-
--
net/bluetooth/l2cap_core.c=7152=static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon)
--
net/bluetooth/l2cap_core.c-7186-
net/bluetooth/l2cap_core.c:7187:	mutex_init(&conn->lock);
net/bluetooth/l2cap_core.c-7188-
--
net/bluetooth/msft.c=753=void msft_register(struct hci_dev *hdev)
--
net/bluetooth/msft.c-767-	hdev->msft_data = msft;
net/bluetooth/msft.c:768:	mutex_init(&msft->filter_lock);
net/bluetooth/msft.c-769-}
--
net/bluetooth/rfcomm/core.c=300=struct rfcomm_dlc *rfcomm_dlc_alloc(gfp_t prio)
--
net/bluetooth/rfcomm/core.c-309-	skb_queue_head_init(&d->tx_queue);
net/bluetooth/rfcomm/core.c:310:	mutex_init(&d->lock);
net/bluetooth/rfcomm/core.c-311-	refcount_set(&d->refcnt, 1);
]

gemini-3.7-flash

							input: 48007
							output: 40
							thoughts: 91
						

**Investigating a Potential Race Condition in Bluetooth Driver Initialization**

Okay, let's dive in. My initial hunch is pointing me towards a potential race condition somewhere within the Bluetooth stack's initialization. Specifically, I need to focus on how mutexes are being handled. My thought process is to trace mutex initialization and pointer publication in `net/bluetooth/msft.c`. I've already noticed something potentially problematic: the `msft_register` function, where `mutex_init` seems to be occurring *after* a pointer might have already been published. That immediately sets off alarm bells for me.

To confirm this suspicion, I'm going to follow the relevant code execution path. I will check `l2cap_conn_add`. I need to understand if this function uses the potential race-prone mutex.

Now, let's get into the details. I need to closely examine lines 7180 to 7200 in `net/bluetooth/l2cap_core.c`. This section likely contains the crucial logic I'm interested in, which involves how `l2cap_conn_add` interacts with the mutex potentially initialized in `msft_register`. This will tell me if the sequence of operations here could create a window for unintended access. I need to see if there's a possibility of concurrent access to a resource before the corresponding mutex protects it.

map[File:net/bluetooth/l2cap_core.c FirstLine:7180 LineCount:25]

map[Contents:7180:		conn->local_fixed_chan = L2CAP_FC_SIG_BREDR | L2CAP_FC_CONNLESS;
7181:	
7182:		if (hci_dev_test_flag(hcon->hdev, HCI_LE_ENABLED) &&
7183:		    (bredr_sc_enabled(hcon->hdev) ||
7184:		     hci_dev_test_flag(hcon->hdev, HCI_FORCE_BREDR_SMP)))
7185:			conn->local_fixed_chan |= L2CAP_FC_SMP_BREDR;
7186:	
7187:		mutex_init(&conn->lock);
7188:	
7189:		INIT_LIST_HEAD(&conn->chan_l);
7190:		INIT_LIST_HEAD(&conn->users);
7191:	
7192:		INIT_DELAYED_WORK(&conn->info_timer, l2cap_info_timeout);
7193:		ida_init(&conn->tx_ida);
7194:	
7195:		skb_queue_head_init(&conn->pending_rx);
7196:		INIT_WORK(&conn->pending_rx_work, process_pending_rx);
7197:		INIT_DELAYED_WORK(&conn->id_addr_timer, l2cap_conn_update_id_addr);
7198:	
7199:		conn->disc_reason = HCI_ERROR_REMOTE_USER_TERM;
7200:	
7201:		return conn;
7202:	}
7203:	
7204:	static bool is_valid_psm(u16 psm, u8 dst_type)
]

gemini-3.7-flash

							input: 48891
							output: 149
							thoughts: 347
						

**Analyzing Potential Synchronization Issues with L2CAP Connection Handling**

Okay, so I'm digging into this L2CAP connection code and something's bugging me. Specifically, in `l2cap_conn_add`, the `conn` struct is only returned *and* assigned to `hcon->l2cap_data` in the calling function, *after* the `l2cap_conn_add` function returns. This feels like a potential race condition or synchronization issue, and it demands further investigation. I need to be absolutely sure this ordering is handled correctly.

Now, let's switch gears and examine the MSFT (Microsoft) extension registration process. I'll take a look at `net/bluetooth/msft.c`: I need to understand how the MSFT extension interacts with the `hci_dev` structure, specifically with `hdev->msft_data`. I'm looking for anything that touches the `hdev` after `l2cap_conn_add` might be called. I'm noting the allocation and initialization of the `msft_data` structure, including the `handle_map`, `address_filters`, and the mutex.

I'm now going to move on to `net/bluetooth/hci_core.c` and focus on how the `hdev` is initialized, specifically how `msft_register` is called. I see the suspend notifier registration, IDR initialization, and the queuing of a work item. The `msft_register(hdev)` call is of particular interest as it sets `hdev->msft_data`. I'm watching the order of things: `msft_register` and related operations and how they might intersect with the `l2cap_conn_add` process.

The plan is to use `codeeditor` to make the edits I think are necessary to ensure proper synchronization and then use `patch-diff` to confirm the changes are sound and that they address any potential concurrency issues. I will also be testing this.

map[CurrentCode:	INIT_LIST_HEAD(&msft->handle_map);
	INIT_LIST_HEAD(&msft->address_filters);
	hdev->msft_data = msft;
	mutex_init(&msft->filter_lock);
} NewCode:	INIT_LIST_HEAD(&msft->handle_map);
	INIT_LIST_HEAD(&msft->address_filters);
	mutex_init(&msft->filter_lock);
	hdev->msft_data = msft;
} SourceFile:net/bluetooth/msft.c]

map[]

gemini-3.7-flash

							input: 49821
							output: 224
							thoughts: 16
						

Here's a summary of my thought process, as if I were about to edit `net/bluetooth/hci_core.c`:

**Diving into HCI Core**

Alright, time to get my hands dirty. It's time to dig into `net/bluetooth/hci_core.c`. I need to remember the architectural layout of this thing like the back of my hand. I already have a pretty good understanding of the HCI layer's role, the command and event flow, and the critical data structures involved (hci_dev, hci_conn, etc.). I need to keep the intricate balance of concurrency and interrupt handling that this core file manages in mind at all times. This is the heart of the Bluetooth stack, so precision and careful consideration are paramount. This file is probably massive, so I'll need to use my understanding of the relevant protocols and Bluetooth specifications, and my debugging skills, to find the exact section I need. Before I even think about making changes, I'll review recent commits and pull requests to understand the context and potential upstream implications. No impulsive coding here.

map[CurrentCode:	error = hci_register_suspend_notifier(hdev);
	if (error)
		BT_WARN("register suspend notifier failed error:%d\n", error);

	queue_work(hdev->req_workqueue, &hdev->power_on);

	idr_init(&hdev->adv_monitors_idr);
	msft_register(hdev);

	return id; NewCode:	error = hci_register_suspend_notifier(hdev);
	if (error)
		BT_WARN("register suspend notifier failed error:%d\n", error);

	idr_init(&hdev->adv_monitors_idr);
	msft_register(hdev);

	queue_work(hdev->req_workqueue, &hdev->power_on);

	return id; SourceFile:net/bluetooth/hci_core.c]

map[]

gemini-3.7-flash

							input: 50295
							output: 10
							thoughts: 12
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert and adopting a first-person perspective:

**Running a Quick Patch Verification**

Right, let's take a quick look at this patch. My immediate thought is, before diving too deep, I should run `patch-diff` and get a really good handle on what's going on with this patch. It's the most expedient way to confirm everything is what I expect. I've got to make sure there are no surprises or obvious issues before I even *think* about applying it or going through it with a fine-tooth comb. Need to establish a good baseline before spending more time on it.

log-in to see details

gemini-3.7-flash

							input: 50486
							output: 15
							thoughts: 15
						

Okay, here's my interpretation of that thought process, assuming I'm deep in the weeds of software development and dealing with a tricky file comparison:

**Analyzing the Call to `patch-diff`**

Alright, so I'm about to call `patch-diff`. This is usually a key utility for me, it's what I rely on to figure out the differences between two files, likely to apply patches or generate them. The real question is: why am I passing an empty string as the `File:` argument? Hmm, that's unusual. It's either a deliberate edge case I'm testing, a placeholder I'll replace later, or potentially something a bit more interesting like wanting to compare to an "empty" file in my mental model. I'll need to figure out what context necessitates this unusual argument. Given my experience, I'm expecting some specific behavior with an empty file name in this particular call. Depending on the library, it could return an error, a default diff, or something entirely context-dependent. Time to dig into the surrounding code and see what I can find!

map[File:]

map[Output:diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2544,104 +2544,104 @@ EXPORT_SYMBOL(hci_free_dev);
 /* Register HCI device */
 int hci_register_dev(struct hci_dev *hdev)
 {
 	int id, error;
 
 	if (!hdev->open || !hdev->close || !hdev->send)
 		return -EINVAL;
 
 	id = ida_alloc_max(&hci_index_ida, HCI_MAX_ID - 1, GFP_KERNEL);
 	if (id < 0)
 		return id;
 
 	error = dev_set_name(&hdev->dev, "hci%u", id);
 	if (error)
 		return error;
 
 	hdev->name = dev_name(&hdev->dev);
 	hdev->id = id;
 
 	BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
 
 	hdev->workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI, hdev->name);
 	if (!hdev->workqueue) {
 		error = -ENOMEM;
 		goto err;
 	}
 
 	hdev->req_workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI,
 						      hdev->name);
 	if (!hdev->req_workqueue) {
 		destroy_workqueue(hdev->workqueue);
 		error = -ENOMEM;
 		goto err;
 	}
 
 	if (!IS_ERR_OR_NULL(bt_debugfs))
 		hdev->debugfs = debugfs_create_dir(hdev->name, bt_debugfs);
 
 	error = device_add(&hdev->dev);
 	if (error < 0)
 		goto err_wqueue;
 
 	hci_leds_init(hdev);
 
 	hdev->rfkill = rfkill_alloc(hdev->name, &hdev->dev,
 				    RFKILL_TYPE_BLUETOOTH, &hci_rfkill_ops,
 				    hdev);
 	if (hdev->rfkill) {
 		if (rfkill_register(hdev->rfkill) < 0) {
 			rfkill_destroy(hdev->rfkill);
 			hdev->rfkill = NULL;
 		}
 	}
 
 	if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
 		hci_dev_set_flag(hdev, HCI_RFKILLED);
 
 	hci_dev_set_flag(hdev, HCI_SETUP);
 	hci_dev_set_flag(hdev, HCI_AUTO_OFF);
 
 	/* Assume BR/EDR support until proven otherwise (such as
 	 * through reading supported features during init.
 	 */
 	hci_dev_set_flag(hdev, HCI_BREDR_ENABLED);
 
 	write_lock(&hci_dev_list_lock);
 	list_add(&hdev->list, &hci_dev_list);
 	write_unlock(&hci_dev_list_lock);
 
 	/* Devices that are marked for raw-only usage are unconfigured
 	 * and should not be included in normal operation.
 	 */
 	if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
 		hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
 
 	/* Mark Remote Wakeup connection flag as supported if driver has wakeup
 	 * callback.
 	 */
 	if (hdev->wakeup)
 		hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
 
 	hci_sock_dev_event(hdev, HCI_DEV_REG);
 	hci_dev_hold(hdev);
 
 	error = hci_register_suspend_notifier(hdev);
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
 	debugfs_remove_recursive(hdev->debugfs);
 	destroy_workqueue(hdev->workqueue);
 	destroy_workqueue(hdev->req_workqueue);
 err:
 	ida_free(&hci_index_ida, hdev->id);
 
 	return error;
 }
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -753,26 +753,26 @@ static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 void msft_register(struct hci_dev *hdev)
 {
 	struct msft_data *msft = NULL;
 
 	bt_dev_dbg(hdev, "Register MSFT extension");
 
 	msft = kzalloc_obj(*msft);
 	if (!msft) {
 		bt_dev_err(hdev, "Failed to register MSFT extension");
 		return;
 	}
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 
 	if (!msft)
 		return;
 
 	bt_dev_dbg(hdev, "Unregister MSFT extension");
]

gemini-3.7-flash

							input: 52407
							output: 393
							thoughts: 48
						

Here's my take on the situation:

**Reflecting on the Clean Fix**

Okay, so I've just reviewed the diff and, yeah, it's pretty satisfying. The changes are clean, to the point, and, critically, they nail down both of those nasty race conditions we were worried about. That issue in `hci_register_dev` was a real headache, and getting rid of that premature pointer publication in `msft_register` is a huge relief. Now, I feel confident we've created a really solid foundation. It's time to craft a comprehensive response, really laying out the specifics of *what* was altered and, even more importantly, *why* these alterations were necessary. We need to document everything clearly, so it's understandable for anyone reviewing the code.

map[PatchDiff:diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)
 TestError:]

map[TestError:]

core

map[ReviewApproved:true ReviewComments:[]]

You are an experienced Linux kernel maintainer reviewing a proposed patch that compiles and passes reproducer tests.
Evaluate the patch diff against the crash report, root cause, and the architectural design guidelines below.

Scope Constraint (Single-Patch Submissions):
We only generate single, standalone patches (not patch series). If a comprehensive architectural redesign would require a multi-patch series touching many files, accept a localized single-patch fix as long as it correctly fixes the bug, does not introduce new issues, and avoids sentinel band-aids within its local scope.

Evaluation:
- Set ReviewApproved=true (and leave ReviewComments empty) if the patch is acceptable for upstream submission as a single-patch fix.
- Set ReviewApproved=false and list concise, actionable feedback in ReviewComments if the patch contains fixable "Kernel Architectural Design & Maintainer Taste" violations.

Don't make assumptions about the kernel source code (it may be different from what you assume it is).
Extensively use the provided code access tools (codesearch-*, git-*, grepper, etc)
to examine the actual source code, and confirm any assumptions.

---

# Kernel Architectural Design & Maintainer Taste

Evaluate kernel patches and fix proposals beyond binary bug presence. Enforce **maintainer taste**, **lifecycle symmetry**, **typestate soundness**, and **topological graph simplicity**.

---

## 1. Core Philosophy: Band-Aid vs. Architectural Design

Naive patches often introduce **defensive sentinel guards** (e.g., ad-hoc `if (!ptr) return;` checks, status flags, or suppressed warnings) directly at the point of failure. While locally avoiding crashes, they degrade subsystem architecture by leaving uninitialized states reachable.

Maintainer "good taste" solves the root cause by **shifting invariants** (making invalid states unrepresentable) and moving dynamic runtime checks into static typestate guarantees.

```
HACKY BAND-AID FIX (Monolithic Cleanup)            ARCHITECTURAL DESIGN (Scoped RAII / Invariant Shift)
───────────────────────────────────────            ────────────────────────────────────────────────────
           [ Init / Entry ]                                         [ Init / Entry ]
                  │                                                         │
      (Register Global Cleanup)                                    (Allocate Resource A)
                  │                                                         │
            [ Init Sub-B ] ──fail──┐                                  [ Init Sub-B ] ──fail──┐
                  │ (success)      │                                        │ (success)      │
                  ▼                │                                        ▼                ▼
          [ Setup Complete ]       │                             (Arm B Cleanup / RAII)  (Unwind A Only:
                  │                │                                        │             B never armed)
         (Deferred Teardown)       │                                        ▼                │
                  │                │                                [ Setup Complete ]       ▼
                  ▼                ▼                                        │            [ Error Exit ]
           [ release_all ] ◄───────┘                               (LIFO Scope Teardown)
                  │                                                         │
      (if (!ctx->b) return;) <-- Defensive guard!                           ▼
                  │                                                [ Clean Destruction ]
           [ Unsafe State ]                                        (Zero sentinel checks needed)
```

```c
// ANTI-PATTERN (Defensive Sentinel Guard): Teardown called on partial init -> callee needs guard
void driver_cleanup(struct ctx *ctx) {
    if (!ctx->buf) return; // <-- Sentinel band-aid
    free_buffer(ctx->buf);
}
// CANONICAL SHIFT (Granular Scoped Action): Registered only upon complete initialization
ctx->buf = alloc_buffer();
if (!ctx->buf) return -ENOMEM;
devm_add_action_or_reset(dev, free_buffer_action, ctx->buf);
```

---

## 2. Maintainer Taste as Graph Topology & Structural Simplicity

Software design quality maps directly to graph-theoretic properties across the Control-Flow Graph (CFG), Data-Flow Graph (DFG), and Object Lifecycle DAG:

### A. Control-Flow Graph (CFG) Simplification
* **Branch Minimization & Path Explosion (McCabe 1976):** Every defensive check added to a compound destructor or callback (`if (!ctx->buffer) return;`) adds a predicate node ($\pi$), increases cyclomatic complexity $v(G) = |E| - |V| + 2$, causes exponential path explosion ($O(2^k)$ paths), and enlarges explicit state spaces ($|S| = \prod |D_i|$). Good taste eliminates the branch by guaranteeing destructors are invoked only on initialized typestates. *(Note: Standard idempotent leaf deallocators like `kfree(NULL)` and public API input sanitizers are exempt).*
* **Single-Entry Single-Exit (SESE) Symmetry (Ferrante 1987, Johnson 1994, Dijkstra 1972):** Resource acquisition and release must form strict **nested dominator trees**. If resource $R_i$ is acquired at node $A$, the set of release actions $\{B_1, \dots, B_m\}$ must form a strict **post-dominating cut** relative to $A$ across all maximal exit paths.
* **Pointer Uniformity (Linus's "Good Taste" Rule):** Eliminate special-case conditional branches by operating on address indirection (e.g., indirect pointers `**curr` in linked list unlinking) to unify edge and interior cases into a branchless invariant.
* **Lexical Scope Invariants & Affine Lifecycles (Wadler 1990, RAII):** Enforce SESE symmetry and "consumed exactly once" affine invariants using compiler-backed scoped cleanup (`<linux/cleanup.h>` `guard()`, `scoped_guard()`, `__free()`).

### B. Ownership & Lifetime DAGs
* **Acyclic Lifecycles & Topological Teardown (Tarjan 1972, Kahn 1962):** Resource ownership must form a strict Directed Acyclic Graph (DAG) $G = (R, E)$. Teardown order must strictly follow reverse topological sort $\text{toposort}(G)^R$. Mixing conflicting lifetime paradigms (e.g., embedding a dynamic refcounted `kref`/socket struct inside a device-managed `devres` buffer or parent container) violates DAG acyclicity, creating synchronous blocking hacks (`wait_for_completion`), circular pins, and Use-After-Free hazards.
* **Three-Phase Concurrent Quiescence:** Multi-threaded and asynchronous teardown (networking, block layer, RCU) must strictly sequence: (1) **Deactivation/Delisting** (make unreachable) -> (2) **Quiescence & Draining** (`synchronize_rcu()`, `cancel_work_sync()`, `napi_disable()`) -> (3) **Physical Reclamation** (`kfree()`, `kmem_cache_destroy()`).
* **Typestate Validity (Strom & Yemini 1986, Aldrich et al. 2009):** A struct with $N$ fields should not use runtime boolean flags (`ctx->is_initialized`) to model incomplete typestates. Sub-resources must transition as a deterministic typestate automaton ($S_{uninit} \xrightarrow{\text{alloc}} S_{init} \xrightarrow{\text{publish}} S_{registered}$), and registration functions must accept only fully initialized typestates.

---

## 3. Deterministic Decision Trigger Matrix

| Code Symptom / Trigger (When you see X) | Anti-Pattern Band-Aid (DO NOT DO Z) | Canonical Invariant Shift (DO Y) |
| :--- | :--- | :--- |
| **Null deref in compound destructor / cleanup callback** | Add `if (!priv->buf) return;` in composite cleanup handler | Register granular cleanup immediately upon allocation via `devm_add_action_or_reset()`, `<linux/cleanup.h>` `__free()`, or discrete reverse LIFO labels |
| **UAF on dynamic object after container unbind** | Allocate with `devm_kzalloc()` and block on `wait_for_completion()` | Allocate with `kzalloc()`, manage lifetime via `kref_get()`/`kref_put()`, call unbind/delist on unbind, free in `kref` release callback |
| **Goto ladder lock leaks on early error exit** | Sprinkle manual `mutex_unlock()` across error returns | Use `guard(mutex)(&lock)` or `scoped_guard(spinlock, &lock)` from `<linux/cleanup.h>` |
| **Callback / IRQ / timer fires before full init** | Add `if (!priv->ready)` check inside IRQ/timer handler | Move `request_irq()`, `timer_setup()`, or `napi_enable()` strictly to the end of setup after all state structures are fully initialized |
| **Multi-step setup failure leaks resources** | Route all errors to a single `err:` label calling a monolithic `cleanup(priv)` with NULL checks | Use `cleanup.h` RAII, granular `devm` actions, or a strict reverse LIFO goto ladder (`err_free_b:` -> `err_free_a:`) |
| **Mixed ownership / asymmetric refcount drops** | Conditionally call `kref_put()` in caller based on error code | Enforce unconditional callee-cleans or caller-cleans ownership convention across all paths |
| **Ad-hoc state flag polling during teardown** | Add `priv->stopping = true` and spin/poll in callbacks | Use atomic typestate transitions and synchronous flush/drain APIs (`cancel_work_sync()`, `drain_workqueue()`) |

---

## 4. The Architectural Review Checklist

Before finalizing any kernel fix or review, audit against the following four criteria:

1. **The Sentinel Test (Caller vs. Callee Responsibility):**
   * *Smell:* Adding a defensive guard (`if (!ptr)` or `if (flags & INITIALIZED)`) inside a compound teardown callback or destructor to mask partial initialization.
   * *Invariant:* If a destructor executes on uninitialized data, the defect is at the **caller's registration/invocation point**, not the callee.
   * *Note:* Standard C allocator no-ops (`kfree(NULL)`) and public API parameter validators (`if (WARN_ON(!ptr)) return -EINVAL;`) are exempt; this rule targets *internal subsystem lifecycle pipelines and teardown paths*.
   * *Action:* Move registration to the point of complete initialization (`devm_add_action_or_reset()`, RAII/`__free()`, or discrete caller unwinding).

2. **LIFO Stack Unwinding Symmetry:**
   * *Smell:* Releasing resources in arbitrary order or invoking destructors for partially initialized subsystems.
   * *Invariant:* Resource release must strictly mirror acquisition order in reverse (LIFO) without monolithic cleanup guards.
   * *Action:* Verify that partial setup/initialization failures (e.g., `probe()`, `mount()`, `open()`, `alloc_pool()`) unwind only already-allocated resources in reverse order via strict LIFO labels or `cleanup.h` scope exit.

3. **Ownership Decoupling:**
   * *Smell:* Embedding dynamically refcounted objects (`kref`, `struct sock`, `struct inode`, `struct file`) directly inside hardware device-bound allocations (`devres`) or parent containers (`super_block`, `net_device`).
   * *Invariant:* Dynamic consumer references must outlive parent unregistration without use-after-free, circular pins, or blocking hacks.
   * *Action:* Decouple the refcounted core object from the container binding; container teardown must unbind/delist the object, but memory is freed exclusively by the final `kref_put()`.

4. **Codebase Idiom Alignment:**
   * *Smell:* Using legacy custom rollback ladders, ad-hoc state flags, or manual lock unlocking on error paths.
   * *Invariant:* Prefer standard, modern kernel abstractions with compiler-enforced safety guarantees.
   * *Action (Modern >= 6.6):* Replace manual boilerplate with `cleanup.h` (`guard()`, `scoped_guard()`, `__free()`), `devm_add_action_or_reset()`, `refcount_t`, and standard `kref` helpers.
   * *Action (Legacy / LTS / No-RAII Subsystems):* Enforce clean, branchless reverse LIFO goto ladders (`err_free_b:` -> `err_free_a:`).
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Bug title:
WARNING in msft_do_close

The crash report:
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf


The root cause explanation:
This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```

The proposed patch diff:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)


Review this patch diff against the crash report, root cause explanation, and kernel architectural design guidelines.

gemini-3.7-flash

							input: 9956
							output: 38
							thoughts: 85
						

Okay, here's my take on those thoughts, framed as my own mental process:

**Diving into This Patch**

Alright, time to really scrutinize this patch and the associated request. I need to get a solid understanding of the changes before I even *think* about signing off. First, I'm going to leverage my usual toolkit. Time to break out `read-file`, `grepper`, `codesearch-*` – whatever's most appropriate – and the `git-*` family of commands. I need a clear picture of the surrounding code and the broader impact. Let's see... I'm particularly interested in how this interacts with the Bluetooth stack. My gut tells me to focus on `net/bluetooth/hci_core.c`, specifically around line 2629. I also want to take a look at `net/bluetooth/msft.c` around line 764. That area tends to be a hotspot for these kinds of modifications. Let's get to it.

map[File:net/bluetooth/hci_core.c FirstLine:2590 LineCount:60]

map[Contents:2590:					    hdev);
2591:		if (hdev->rfkill) {
2592:			if (rfkill_register(hdev->rfkill) < 0) {
2593:				rfkill_destroy(hdev->rfkill);
2594:				hdev->rfkill = NULL;
2595:			}
2596:		}
2597:	
2598:		if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
2599:			hci_dev_set_flag(hdev, HCI_RFKILLED);
2600:	
2601:		hci_dev_set_flag(hdev, HCI_SETUP);
2602:		hci_dev_set_flag(hdev, HCI_AUTO_OFF);
2603:	
2604:		/* Assume BR/EDR support until proven otherwise (such as
2605:		 * through reading supported features during init.
2606:		 */
2607:		hci_dev_set_flag(hdev, HCI_BREDR_ENABLED);
2608:	
2609:		write_lock(&hci_dev_list_lock);
2610:		list_add(&hdev->list, &hci_dev_list);
2611:		write_unlock(&hci_dev_list_lock);
2612:	
2613:		/* Devices that are marked for raw-only usage are unconfigured
2614:		 * and should not be included in normal operation.
2615:		 */
2616:		if (hci_test_quirk(hdev, HCI_QUIRK_RAW_DEVICE))
2617:			hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
2618:	
2619:		/* Mark Remote Wakeup connection flag as supported if driver has wakeup
2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
]

gemini-3.7-flash

							input: 11214
							output: 36
							thoughts: 14
						

Here's my take on the thought process, as requested:

**Diving into `net/bluetooth/msft.c`**

Okay, time to get to it. The immediate need here is to dive into `net/bluetooth/msft.c`. I need to figure out what's going on within that specific file related to Microsoft Bluetooth drivers. This probably means I'm troubleshooting, or maybe I'm working on an enhancement, or perhaps just doing some code review. Given my expertise, I'm already mentally running through the various data structures and key functions that are likely defined or used within that file. I'm expecting to see calls related to initialization, device handling, HCI commands, maybe even some specific error handling related to the Microsoft implementation of the Bluetooth protocol stack. The fact that the file's named after MSFT clearly indicates a specific implementation of Bluetooth, and I'm going to leverage my existing knowledge of Bluetooth profiles and the Linux networking stack to quickly understand the nuances of this implementation. Let's start digging!

map[File:net/bluetooth/msft.c FirstLine:740 LineCount:40]

map[Contents: 740:			goto done;
 741:		}
 742:		kfree_skb(skb);
 743:	
 744:		bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
 745:			   &address_filter->bdaddr);
 746:	
 747:	done:
 748:		kfree(address_filter);
 749:	
 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
]

gemini-3.7-flash

							input: 12013
							output: 38
							thoughts: 60
						

Okay, let's dive into this. I need to get a comprehensive grasp of `hci_register_dev`. To truly understand how `hdev` and its associated resources are managed within this function, I'll need to dissect the entire process. I'm going to focus my attention on the code block from line 2500 through 2649. Let's see what the lifecycle holds within that segment.

map[File:net/bluetooth/hci_core.c FirstLine:2500 LineCount:95]

map[Contents:2500:		INIT_LIST_HEAD(&hdev->pend_le_conns);
2501:		INIT_LIST_HEAD(&hdev->pend_le_reports);
2502:		INIT_LIST_HEAD(&hdev->conn_hash.list);
2503:		INIT_LIST_HEAD(&hdev->adv_instances);
2504:		INIT_LIST_HEAD(&hdev->blocked_keys);
2505:		INIT_LIST_HEAD(&hdev->monitored_devices);
2506:	
2507:		INIT_LIST_HEAD(&hdev->local_codecs);
2508:		INIT_WORK(&hdev->rx_work, hci_rx_work);
2509:		INIT_WORK(&hdev->cmd_work, hci_cmd_work);
2510:		INIT_WORK(&hdev->tx_work, hci_tx_work);
2511:		INIT_WORK(&hdev->power_on, hci_power_on);
2512:		INIT_WORK(&hdev->error_reset, hci_error_reset);
2513:	
2514:		hci_cmd_sync_init(hdev);
2515:	
2516:		INIT_DELAYED_WORK(&hdev->power_off, hci_power_off);
2517:	
2518:		skb_queue_head_init(&hdev->rx_q);
2519:		skb_queue_head_init(&hdev->cmd_q);
2520:		skb_queue_head_init(&hdev->raw_q);
2521:	
2522:		init_waitqueue_head(&hdev->req_wait_q);
2523:	
2524:		INIT_DELAYED_WORK(&hdev->cmd_timer, hci_cmd_timeout);
2525:		INIT_DELAYED_WORK(&hdev->ncmd_timer, hci_ncmd_timeout);
2526:	
2527:		hci_devcd_setup(hdev);
2528:	
2529:		hci_init_sysfs(hdev);
2530:		discovery_init(hdev);
2531:	
2532:		return hdev;
2533:	}
2534:	EXPORT_SYMBOL(hci_alloc_dev_priv);
2535:	
2536:	/* Free HCI device */
2537:	void hci_free_dev(struct hci_dev *hdev)
2538:	{
2539:		/* will free via device release */
2540:		put_device(&hdev->dev);
2541:	}
2542:	EXPORT_SYMBOL(hci_free_dev);
2543:	
2544:	/* Register HCI device */
2545:	int hci_register_dev(struct hci_dev *hdev)
2546:	{
2547:		int id, error;
2548:	
2549:		if (!hdev->open || !hdev->close || !hdev->send)
2550:			return -EINVAL;
2551:	
2552:		id = ida_alloc_max(&hci_index_ida, HCI_MAX_ID - 1, GFP_KERNEL);
2553:		if (id < 0)
2554:			return id;
2555:	
2556:		error = dev_set_name(&hdev->dev, "hci%u", id);
2557:		if (error)
2558:			return error;
2559:	
2560:		hdev->name = dev_name(&hdev->dev);
2561:		hdev->id = id;
2562:	
2563:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2564:	
2565:		hdev->workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI, hdev->name);
2566:		if (!hdev->workqueue) {
2567:			error = -ENOMEM;
2568:			goto err;
2569:		}
2570:	
2571:		hdev->req_workqueue = alloc_ordered_workqueue("%s", WQ_HIGHPRI,
2572:							      hdev->name);
2573:		if (!hdev->req_workqueue) {
2574:			destroy_workqueue(hdev->workqueue);
2575:			error = -ENOMEM;
2576:			goto err;
2577:		}
2578:	
2579:		if (!IS_ERR_OR_NULL(bt_debugfs))
2580:			hdev->debugfs = debugfs_create_dir(hdev->name, bt_debugfs);
2581:	
2582:		error = device_add(&hdev->dev);
2583:		if (error < 0)
2584:			goto err_wqueue;
2585:	
2586:		hci_leds_init(hdev);
2587:	
2588:		hdev->rfkill = rfkill_alloc(hdev->name, &hdev->dev,
2589:					    RFKILL_TYPE_BLUETOOTH, &hci_rfkill_ops,
2590:					    hdev);
2591:		if (hdev->rfkill) {
2592:			if (rfkill_register(hdev->rfkill) < 0) {
2593:				rfkill_destroy(hdev->rfkill);
2594:				hdev->rfkill = NULL;
]

gemini-3.7-flash

							input: 13728
							output: 38
							thoughts: 53
						

Here's my take on those thoughts:

**Dissecting the Device Unregistration Process**

Alright, time to dive into `hci_unregister_dev(struct hci_dev *hdev)`. I need to understand exactly what happens here. My first instinct is to either jump directly into the source code and locate the function, or if I remember where the common functions are, I'll start by checking around line 2650 in `hci_core.c`. Let's see what secrets this unregistration holds.

map[File:net/bluetooth/hci_core.c FirstLine:2650 LineCount:70]

map[Contents:2650:	/* Unregister HCI device */
2651:	void hci_unregister_dev(struct hci_dev *hdev)
2652:	{
2653:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2654:	
2655:		mutex_lock(&hdev->unregister_lock);
2656:		hci_dev_set_flag(hdev, HCI_UNREGISTER);
2657:		mutex_unlock(&hdev->unregister_lock);
2658:	
2659:		write_lock(&hci_dev_list_lock);
2660:		list_del(&hdev->list);
2661:		write_unlock(&hci_dev_list_lock);
2662:	
2663:		synchronize_srcu(&hdev->srcu);
2664:		cleanup_srcu_struct(&hdev->srcu);
2665:	
2666:		disable_work_sync(&hdev->rx_work);
2667:		disable_work_sync(&hdev->cmd_work);
2668:		disable_work_sync(&hdev->tx_work);
2669:		disable_work_sync(&hdev->power_on);
2670:		disable_work_sync(&hdev->error_reset);
2671:		disable_delayed_work_sync(&hdev->cmd_timer);
2672:		disable_delayed_work_sync(&hdev->ncmd_timer);
2673:	
2674:		hci_cmd_sync_clear(hdev);
2675:	
2676:		hci_unregister_suspend_notifier(hdev);
2677:	
2678:		hci_dev_do_close(hdev);
2679:	
2680:		if (!test_bit(HCI_INIT, &hdev->flags) &&
2681:		    !hci_dev_test_flag(hdev, HCI_SETUP) &&
2682:		    !hci_dev_test_flag(hdev, HCI_CONFIG)) {
2683:			hci_dev_lock(hdev);
2684:			mgmt_index_removed(hdev);
2685:			hci_dev_unlock(hdev);
2686:		}
2687:	
2688:		/* mgmt_index_removed should take care of emptying the
2689:		 * pending list */
2690:		BUG_ON(!list_empty(&hdev->mgmt_pending));
2691:	
2692:		hci_sock_dev_event(hdev, HCI_DEV_UNREG);
2693:	
2694:		if (hdev->rfkill) {
2695:			rfkill_unregister(hdev->rfkill);
2696:			rfkill_destroy(hdev->rfkill);
2697:		}
2698:	
2699:		device_del(&hdev->dev);
2700:		/* Actual cleanup is deferred until hci_release_dev(). */
2701:		hci_dev_put(hdev);
2702:	}
2703:	EXPORT_SYMBOL(hci_unregister_dev);
2704:	
2705:	/* Release HCI device */
2706:	void hci_release_dev(struct hci_dev *hdev)
2707:	{
2708:		debugfs_remove_recursive(hdev->debugfs);
2709:		kfree_const(hdev->hw_info);
2710:		kfree_const(hdev->fw_info);
2711:	
2712:		destroy_workqueue(hdev->workqueue);
2713:		destroy_workqueue(hdev->req_workqueue);
2714:	
2715:		hci_dev_lock(hdev);
2716:		hci_bdaddr_list_clear(&hdev->reject_list);
2717:		hci_bdaddr_list_clear(&hdev->accept_list);
2718:		hci_uuids_clear(hdev);
2719:		hci_link_keys_clear(hdev);
]

gemini-3.7-flash

							input: 15057
							output: 38
							thoughts: 52
						

**Investigating `adv_monitors_idr` Usage**

Alright, let's dive in. I need to understand the call sites for `msft_release` and `idr_destroy` related to the `adv_monitors_idr` structure. This is a common debugging approach; pinpointing where these key functions are invoked will illuminate how this `idr` is managed. My initial instinct, based on the codebase, is to start with `hci_core.c`. Let's zero in on the lines around 2720, perhaps a bit further, to see if we can catch the relevant code. Time to dig in and see what's actually going on in there!

map[File:net/bluetooth/hci_core.c FirstLine:2720 LineCount:40]

map[Contents:2720:		hci_smp_ltks_clear(hdev);
2721:		hci_smp_irks_clear(hdev);
2722:		hci_remote_oob_data_clear(hdev);
2723:		hci_adv_instances_clear(hdev);
2724:		hci_adv_monitors_clear(hdev);
2725:		hci_bdaddr_list_clear(&hdev->le_accept_list);
2726:		hci_bdaddr_list_clear(&hdev->le_resolv_list);
2727:		hci_conn_params_clear_all(hdev);
2728:		hci_discovery_filter_clear(hdev);
2729:		hci_blocked_keys_clear(hdev);
2730:		hci_codec_list_clear(&hdev->local_codecs);
2731:		msft_release(hdev);
2732:		hci_dev_unlock(hdev);
2733:	
2734:		ida_destroy(&hdev->unset_handle_ida);
2735:		ida_free(&hci_index_ida, hdev->id);
2736:		kfree_skb(hdev->sent_cmd);
2737:		kfree_skb(hdev->req_skb);
2738:		kfree_skb(hdev->recv_event);
2739:		kfree(hdev);
2740:	}
2741:	EXPORT_SYMBOL(hci_release_dev);
2742:	
2743:	int hci_register_suspend_notifier(struct hci_dev *hdev)
2744:	{
2745:		int ret = 0;
2746:	
2747:		if (!hdev->suspend_notifier.notifier_call &&
2748:		    !hci_test_quirk(hdev, HCI_QUIRK_NO_SUSPEND_NOTIFIER)) {
2749:			hdev->suspend_notifier.notifier_call = hci_suspend_notifier;
2750:			ret = register_pm_notifier(&hdev->suspend_notifier);
2751:		}
2752:	
2753:		return ret;
2754:	}
2755:	
2756:	int hci_unregister_suspend_notifier(struct hci_dev *hdev)
2757:	{
2758:		int ret = 0;
2759:	
]

gemini-3.7-flash

							input: 15974
							output: 52
							thoughts: 51
						

Okay, let's dive into this code.

**Investigating `msft_do_close` and the `msft` System**

Right, my immediate focus is understanding the call sites for `msft_do_close` and, by extension, how the `msft` system functions. I need to trace its usage to grasp its overall impact. So, the first logical step is to use a powerful reference-finding tool. `codesearch-find-references` or `grepper` – either will do – should provide a comprehensive list of every instance where `msft_do_close` is invoked. This will illuminate the context in which it operates. Knowing *where* it's called is crucial to understanding *why* it's called. This is the starting point for a deeper exploration of the `msft` system.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:10 Name:msft_do_close SourceTreePrefix:]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_dev_close_sync SourceFile:net/bluetooth/hci_sync.c SourceLine:5522 SourceSnippet:5512:		hci_pend_le_actions_clear(hdev);
5513:		hci_conn_hash_flush(hdev);
5514:		/* Prevent data races on hdev->smp_data or hdev->smp_bredr_data */
5515:		smp_unregister(hdev);
5516:		hci_dev_unlock(hdev);
5517:	
5518:		hci_sock_dev_event(hdev, HCI_DEV_DOWN);
5519:	
5520:		if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
5521:			aosp_do_close(hdev);
5522:			msft_do_close(hdev);
5523:		}
5524:	
5525:		if (hdev->flush)
5526:			hdev->flush(hdev);
5527:	
5528:		/* Reset device */
5529:		skb_queue_purge(&hdev->cmd_q);
5530:		atomic_set(&hdev->cmd_cnt, 1);
5531:		hdev->acl_cnt = 0;
5532:		hdev->sco_cnt = 0;
]] TruncatedOutput:false]

gemini-3.7-flash

							input: 16672
							output: 36
							thoughts: 40
						

Here's my take on those thoughts:

**Analyzing the Microsoft Bluetooth Close Function**

Alright, let's dive in. I need to understand the behavior of this `msft_do_close` function. My instinct tells me that the implementation of a close function will be critical to understand how the driver handles device disconnection, resource release, and potentially error handling.

To get a handle on what's happening, I'll go straight to the source. Specifically, I need to check out the `net/bluetooth/msft.c` file. Given what I'm looking for, my guess is that the key operations and any cleanup routines within the function that is responsible for closing the device should be in the `680-720` line region. That should give me the core logic without getting bogged down in unrelated details. Time to get my eyes on that code.

map[File:net/bluetooth/msft.c FirstLine:680 LineCount:40]

map[Contents: 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
 700:	
 701:		hci_dev_lock(hdev);
 702:	
 703:		/* Clear any devices that are being monitored and notify device lost */
 704:		hdev->advmon_pend_notify = false;
 705:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 706:	
 707:		hci_dev_unlock(hdev);
 708:	}
 709:	
 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
 715:		struct sk_buff *skb;
 716:		int err = 0;
 717:	
 718:		if (!msft) {
 719:			bt_dev_err(hdev, "MSFT: msft data is freed");
]

gemini-3.7-flash

							input: 17595
							output: 36
							thoughts: 41
						

Okay, let's dive into this. Here's how I'd approach this task, as if these were my internal thoughts:

**Analyzing the `msft_do_close` Function**

Alright, time to examine the `msft_do_close` function. It looks like understanding its initial setup is crucial. My first step is to zero in on a specific section of code to get a handle on the function's intended purpose. Specifically, I need to see what's happening at the start. Reading lines 660 to 680 of `net/bluetooth/msft.c` should give me a good picture of the context and any initial conditions. This will probably involve looking for initialization steps, resource cleanup, or maybe some key conditional checks. Getting the lay of the land quickly is always a good starting point.

map[File:net/bluetooth/msft.c FirstLine:660 LineCount:25]

map[Contents: 660:			/* Monitors get removed on power off, so we need to explicitly
 661:			 * tell the controller to re-monitor.
 662:			 */
 663:			reregister_monitor(hdev);
 664:		}
 665:	}
 666:	
 667:	void msft_do_close(struct hci_dev *hdev)
 668:	{
 669:		struct msft_data *msft = hdev->msft_data;
 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
]

gemini-3.7-flash

							input: 18255
							output: 38
							thoughts: 131
						

**Analyzing a Potential Race Condition**

Okay, let's break this down. I'm looking at `msft_do_close`. My immediate concern is the interaction with `hdev->adv_monitors_idr`, `msft->handle_map`, and `msft->filter_lock`. That's where things can get dicey. The question is, if `hdev->power_on` – which I know triggers `hci_power_on` – gets called *before* `idr_init(&hdev->adv_monitors_idr)` and `msft_register(hdev)` are properly set up, what's the possible fallout? It's a classic initialization race condition scenario. Let's trace it back. So `power_on` calls `hci_power_on()`. Alright, I'll need to check the definition of `hci_power_on` in `net/bluetooth/hci_core.c` and verify how this all interacts.

map[ContextFile:net/bluetooth/hci_core.c Name:hci_power_on]

map[SourceCode: 904:	static void hci_power_on(struct work_struct *work)
 905:	{
 906:		struct hci_dev *hdev = container_of(work, struct hci_dev, power_on);
 907:		int err;
 908:	
 909:		BT_DBG("%s", hdev->name);
 910:	
 911:		if (test_bit(HCI_UP, &hdev->flags) &&
 912:		    hci_dev_test_flag(hdev, HCI_MGMT) &&
 913:		    hci_dev_test_and_clear_flag(hdev, HCI_AUTO_OFF)) {
 914:			cancel_delayed_work(&hdev->power_off);
 915:			err = hci_powered_update_sync(hdev);
 916:			mgmt_power_on(hdev, err);
 917:			return;
 918:		}
 919:	
 920:		err = hci_dev_do_open(hdev);
 921:		if (err < 0) {
 922:			hci_dev_lock(hdev);
 923:			mgmt_set_powered_failed(hdev, err);
 924:			hci_dev_unlock(hdev);
 925:			return;
 926:		}
 927:	
 928:		/* During the HCI setup phase, a few error conditions are
 929:		 * ignored and they need to be checked now. If they are still
 930:		 * valid, it is important to turn the device back off.
 931:		 */
 932:		if (hci_dev_test_flag(hdev, HCI_RFKILLED) ||
 933:		    hci_dev_test_flag(hdev, HCI_UNCONFIGURED) ||
 934:		    (!bacmp(&hdev->bdaddr, BDADDR_ANY) &&
 935:		     !bacmp(&hdev->static_addr, BDADDR_ANY))) {
 936:			hci_dev_clear_flag(hdev, HCI_AUTO_OFF);
 937:			hci_dev_do_close(hdev);
 938:		} else if (hci_dev_test_flag(hdev, HCI_AUTO_OFF)) {
 939:			queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
 940:					   HCI_AUTO_OFF_TIMEOUT);
 941:		}
 942:	
 943:		if (hci_dev_test_and_clear_flag(hdev, HCI_SETUP)) {
 944:			/* For unconfigured devices, set the HCI_RAW flag
 945:			 * so that userspace can easily identify them.
 946:			 */
 947:			if (hci_dev_test_flag(hdev, HCI_UNCONFIGURED))
 948:				set_bit(HCI_RAW, &hdev->flags);
 949:	
 950:			/* For fully configured devices, this will send
 951:			 * the Index Added event. For unconfigured devices,
 952:			 * it will send Unconfigued Index Added event.
 953:			 *
 954:			 * Devices with HCI_QUIRK_RAW_DEVICE are ignored
 955:			 * and no event will be send.
 956:			 */
 957:			mgmt_index_added(hdev);
 958:		} else if (hci_dev_test_and_clear_flag(hdev, HCI_CONFIG)) {
 959:			/* When the controller is now configured, then it
 960:			 * is important to clear the HCI_RAW flag.
 961:			 */
 962:			if (!hci_dev_test_flag(hdev, HCI_UNCONFIGURED))
 963:				clear_bit(HCI_RAW, &hdev->flags);
 964:	
 965:			/* Powering on the controller with HCI_CONFIG set only
 966:			 * happens with the transition from unconfigured to
 967:			 * configured. This will send the Index Added event.
 968:			 */
 969:			mgmt_index_added(hdev);
 970:		}
 971:	}
 SourceFile:net/bluetooth/hci_core.c]

gemini-3.7-flash

							input: 19819
							output: 35
							thoughts: 183
						

**Analyzing the Device Registration Process**

Okay, let's break down this `hci_register_dev` function. First, I see the typical device registration and hold process with `hci_sock_dev_event` and `hci_dev_hold`. Then, there's the standard suspend notifier registration, with a warning if it fails. The power-on workqueue is queued. So far, so good, standard stuff.

Now, here's where it gets interesting: the `idr_init` call followed by `msft_register`. I need to understand the history of this. When were these lines added? I need to check the Git log for `hci_register_dev` to see the commit history and understand the context behind these additions. What functionality do `idr_init` and `msft_register` provide? Are these features specific to certain devices or part of a more general enhancement? The log should provide the answers, tracing back to the relevant commit messages and any associated discussions. That's my next step.

log-in to see details

map[Count:5 PathPrefix:net/bluetooth/ SymbolName:hci_register_dev]

map[Output:]

gemini-3.7-flash

							input: 20279
							output: 40
							thoughts: 19
						

Here's my take on those thoughts:

**Thinking Through Git Log and Symbols**

Okay, so I need to dig into the git history, specifically focusing on a `SymbolName` within a `SourcePath`. That's a classic situation where `git-log` is going to be my best friend. I'm immediately envisioning the command line, crafting a query that filters the log messages. I need to make sure I include those key pieces of information as arguments. I'm thinking I'll need some robust filtering options, maybe `--grep` to focus on the `SymbolName`, and I'll almost certainly need to specify the `SourcePath` somehow, probably with a file path specifier. I'll need to remember to check the output format, too, to make sure it's presenting the results in a way I can easily parse and process. I'll need to tailor it to be useful for the investigation. Let's get to work.

map[Count:5 SourcePath:net/bluetooth/hci_core.c SymbolName:hci_register_dev]

map[Output:6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
84a4bb6548a2 Bluetooth: HCI: Remove HCI_AMP support
9c16d0c8d93e Bluetooth: Remove usage of the deprecated ida_simple_xx() API
dcda165706b9 Bluetooth: hci_core: Fix build warnings
0d75da38e060 Bluetooth: hci_core: fix error handling in hci_register_dev()
]

gemini-3.7-flash

							input: 20682
							output: 40
							thoughts: 44
						

Okay, let's dive into this. I need to understand the context surrounding the addition of `idr_init(&hdev->adv_monitors_idr)` and `msft_register(hdev)` in `hci_core.c`. This strongly suggests a Microsoft-specific feature or interaction related to the Bluetooth host controller driver, given the `msft_register` call. The `idr_init` call suggests the initialization of an IDR (Integer Descriptor Region), so it is very likely used to manage a dynamically allocated resource of some kind related to the advanced monitor feature, perhaps to track some kind of monitoring session or registration within the Bluetooth system on Windows. So I need to go back in the commit history for this file, `hci_core.c`, to pinpoint when these were added. My immediate goal is to understand the *why* behind this implementation. What problem was being solved, and what other changes were introduced alongside this? Specifically, I'll be looking for any accompanying commit messages or code comments that provide more insight into the purpose of `hdev->adv_monitors_idr` and `msft_register`. I want to see if the IDR is tracking monitor sessions, which is my strongest hypothesis.

log-in to see details

map[CodeRegexp:msft_register Count:5 SourcePath:net/bluetooth/hci_core.c]

map[Output:]

gemini-3.7-flash

							input: 21061
							output: 39
							thoughts: 34
						

Okay, here's my interpretation of that thought process, as if it were my own:

**Investigating a Bluetooth HCI Issue**

Right, time to dig into this Bluetooth HCI core code. I need to understand what's happening around lines 2625-2640 of `net/bluetooth/hci_core.c`. My first instinct, given my experience, is to reach for `git blame`. It's the most efficient way to see *who* last touched this section and *why*. Understanding the recent history of this code is crucial. It gives me immediate context – who was working on it, what changes were made, and perhaps, the rationale behind those changes. That information will hopefully point me toward the root cause of the issue I'm dealing with. Let's see what the blame tool reveals.

map[End:2640 File:net/bluetooth/hci_core.c Start:2625]

map[Output:05fcd4c4f1011 2625) 	hci_sock_dev_event(hdev, HCI_DEV_REG);
dc946bd86f725 2626) 	hci_dev_hold(hdev);
^1da177e4c3f4 2627) 
9111786492f13 2628) 	error = hci_register_suspend_notifier(hdev);
9111786492f13 2629) 	if (error)
0d75da38e060d 2630) 		BT_WARN("register suspend notifier failed error:%d\n", error);
9952d90ea2885 2631) 
1920257316615 2632) 	queue_work(hdev->req_workqueue, &hdev->power_on);
fbe96d6ff9f4e 2633) 
e5e1e7fd470cc 2634) 	idr_init(&hdev->adv_monitors_idr);
5031ffcc79b81 2635) 	msft_register(hdev);
e5e1e7fd470cc 2636) 
^1da177e4c3f4 2637) 	return id;
f48fd9c8cd746 2638) 
33ca954daf1ac 2639) err_wqueue:
5a4bb6a8e981d 2640) 	debugfs_remove_recursive(hdev->debugfs);
]

gemini-3.7-flash

							input: 21771
							output: 26
							thoughts: 161
						

**Analyzing Recent Driver Initialization Changes**

Okay, so I'm looking at this sequence of events in the driver initialization. Interesting. First, I see that this job, `1920257316615`, queued a `power_on` work. Standard stuff, that's expected.

Then, commit `e5e1e7fd470cc` adds `idr_init(&hdev->adv_monitors_idr)` within `hci_register_dev()`. Right, initializing the IDR for advanced monitor management, makes sense given the context of what else is being initialized. This seems related to resource tracking. I'll need to remember that.

And *then*, commit `5031ffcc79b81` jumps in and adds `msft_register(hdev)` right after the `queue_work(hdev->req_workqueue, &hdev->power_on)` call. Now *that's* the key. It looks like the Microsoft-specific registration is occurring immediately after the power-on work is queued. That might be a potential issue if `msft_register` requires the device to be at least partially powered on. Or it might be fine, but the order of operations warrants further investigation. I'm going to have to dive into those two commits – `5031ffcc79b81` and `e5e1e7fd470cc` specifically – to understand the potential dependencies and if that ordering is intended, and if any synchronization or error handling has been considered. I need to understand why that call is there, and why it is placed where it is.

map[Commit:5031ffcc79b81]

map[Output:commit 5031ffcc79b81776ac8f7f8b1a585aed8818e3d1
Author: Miao-chen Chou <mcchou@chromium.org>
Date:   Thu Sep 9 14:10:23 2021 -0700

    Bluetooth: Keep MSFT ext info throughout a hci_dev's life cycle
    
    This splits the msft_do_{open/close} to msft_do_{open/close} and
    msft_{register/unregister}. With this change it is possible to retain
    the MSFT extension info irrespective of controller power on/off state.
    This helps bluetoothd to report correct 'supported features' of the
    controller to the D-Bus clients event if the controller is off. It also
    re-reads the MSFT info upon every msft_do_open().
    
    The following test steps were performed.
    1. Boot the test device and verify the MSFT support debug log in syslog.
    2. Power off the controller and read the 'supported features', power on
       and read again.
    3. Restart the bluetoothd and verify the 'supported features' value.
    
    Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Reviewed-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Alain Michaud <alainm@chromium.org>
    Signed-off-by: Manish Mandlik <mmandlik@google.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5236faa397fa..beda5dac1658 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3990,6 +3990,7 @@ int hci_register_dev(struct hci_dev *hdev)
 	queue_work(hdev->req_workqueue, &hdev->power_on);
 
 	idr_init(&hdev->adv_monitors_idr);
+	msft_register(hdev);
 
 	return id;
 
@@ -4022,6 +4023,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
 		cancel_work_sync(&hdev->suspend_prepare);
 	}
 
+	msft_unregister(hdev);
+
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index b4bfae41e8a5..21b1787e7893 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -184,28 +184,36 @@ static void reregister_monitor_on_restart(struct hci_dev *hdev, int handle)
 
 void msft_do_open(struct hci_dev *hdev)
 {
-	struct msft_data *msft;
+	struct msft_data *msft = hdev->msft_data;
 
 	if (hdev->msft_opcode == HCI_OP_NOP)
 		return;
 
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT extension not registered");
+		return;
+	}
+
 	bt_dev_dbg(hdev, "Initialize MSFT extension");
 
-	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
-	if (!msft)
-		return;
+	/* Reset existing MSFT data before re-reading */
+	kfree(msft->evt_prefix);
+	msft->evt_prefix = NULL;
+	msft->evt_prefix_len = 0;
+	msft->features = 0;
 
 	if (!read_supported_features(hdev, msft)) {
+		hdev->msft_data = NULL;
 		kfree(msft);
 		return;
 	}
 
-	INIT_LIST_HEAD(&msft->handle_map);
-	hdev->msft_data = msft;
-
 	if (msft_monitor_supported(hdev)) {
 		msft->reregistering = true;
 		msft_set_filter_enable(hdev, true);
+		/* Monitors get removed on power off, so we need to explicitly
+		 * tell the controller to re-monitor.
+		 */
 		reregister_monitor_on_restart(hdev, 0);
 	}
 }
@@ -221,8 +229,9 @@ void msft_do_close(struct hci_dev *hdev)
 
 	bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 
-	hdev->msft_data = NULL;
-
+	/* The controller will silently remove all monitors on power off.
+	 * Therefore, remove handle_data mapping and reset monitor state.
+	 */
 	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 		monitor = idr_find(&hdev->adv_monitors_idr,
 				   handle_data->mgmt_handle);
@@ -233,6 +242,34 @@ void msft_do_close(struct hci_dev *hdev)
 		list_del(&handle_data->list);
 		kfree(handle_data);
 	}
+}
+
+void msft_register(struct hci_dev *hdev)
+{
+	struct msft_data *msft = NULL;
+
+	bt_dev_dbg(hdev, "Register MSFT extension");
+
+	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
+	if (!msft) {
+		bt_dev_err(hdev, "Failed to register MSFT extension");
+		return;
+	}
+
+	INIT_LIST_HEAD(&msft->handle_map);
+	hdev->msft_data = msft;
+}
+
+void msft_unregister(struct hci_dev *hdev)
+{
+	struct msft_data *msft = hdev->msft_data;
+
+	if (!msft)
+		return;
+
+	bt_dev_dbg(hdev, "Unregister MSFT extension");
+
+	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
 	kfree(msft);
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 6e56d94b88d8..8018948c5975 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -13,6 +13,8 @@
 #if IS_ENABLED(CONFIG_BT_MSFTEXT)
 
 bool msft_monitor_supported(struct hci_dev *hdev);
+void msft_register(struct hci_dev *hdev);
+void msft_unregister(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb);
@@ -31,6 +33,8 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 	return false;
 }
 
+static inline void msft_register(struct hci_dev *hdev) {}
+static inline void msft_unregister(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb) {}
]

gemini-3.7-flash

							input: 24414
							output: 28
							thoughts: 53
						

**Investigating the Evolution of `msft_unregister` and the Emergence of `msft_release`**

Okay, so I need to understand the relationship between `msft_unregister` and the newer `msft_release` function. What led to this change? I'll start by tracing the history. My first thought is to dive into the code and search. Let's start with `net/bluetooth/msft.c`. I'll look for instances of `msft_release` directly, but I should also check the commit history within that file. That should give me a chronological view of the changes, showing how `msft_release` came into being, and hopefully illuminate why the older `msft_unregister` was superseded, or if it was? I'm curious to see the rationale behind the change. Time to dig in!

map[Count:5 PathPrefix:net/bluetooth/msft.c]

map[Output:384a4b2fef9f Bluetooth: MGMT: Fix adv monitor add failure cleanup
bf4afc53b77a Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar types
6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
936daee9cf08 Bluetooth: Remove hci_request.{c,h}
]

gemini-3.7-flash

							input: 24823
							output: 36
							thoughts: 24
						

Okay, here's my take on those thoughts, tailored for an expert audience, and written as if they were my own:

**Diving into the `msft_release` Implementation**

Alright, time to get to the heart of this. My initial thought process has me focusing on `msft_release`. I know it's a critical function, especially in the context of the Microsoft-specific Bluetooth handling. I want to see precisely how it's implemented within `net/bluetooth/msft.c`. I need a clear understanding of its operation to properly assess the overall architecture. I'm looking for the nitty-gritty details; how it interacts with other data structures, what resources it's cleaning up, and if there are any subtle race conditions or memory management issues I might need to consider. I'm basically going to dissect the code and look for anything that might impact system stability, security, or overall performance when interacting with Microsoft devices. This is where the devil is always in the details!

map[ContextFile:net/bluetooth/msft.c Name:msft_release]

map[SourceCode: 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
 780:		hdev->msft_data = NULL;
 781:	
 782:		kfree(msft->evt_prefix);
 783:		mutex_destroy(&msft->filter_lock);
 784:		kfree(msft);
 785:	}
 SourceFile:net/bluetooth/msft.c]

gemini-3.7-flash

							input: 25324
							output: 30
							thoughts: 82
						

**Investigating Potential Errors in HCI Device Registration and Monitor Cleanup**

Okay, so I'm looking into the error handling and cleanup procedures surrounding the `hci_register_dev` function. Specifically, I'm trying to understand what happens if that function fails. My immediate concern is how `adv_monitors_idr` and `msft_data` are managed in such a scenario. I need to ensure they're properly cleaned up, so that there aren't any memory leaks or resource issues.

Wait a minute, let me take a step back and examine the lifecycle of `adv_monitors_idr`. That's the core of the issue, right? I need to know where it's initialized, used, and, crucially, destroyed. I'm going to start by confirming where `idr_destroy` is called for `adv_monitors_idr`, as that will tell the complete picture of the whole lifecycle and if there are any potential gaps that need further attention.

Let me do a quick grep for `adv_monitors_idr` throughout the codebase, in order to get all callsites in context.

map[Expression:adv_monitors_idr PathPrefix:net/bluetooth]

map[Output:net/bluetooth/hci_core.c=1841=void hci_adv_monitors_clear(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-1845-
net/bluetooth/hci_core.c:1846:	idr_for_each_entry(&hdev->adv_monitors_idr, monitor, handle)
net/bluetooth/hci_core.c-1847-		hci_free_adv_monitor(hdev, monitor);
net/bluetooth/hci_core.c-1848-
net/bluetooth/hci_core.c:1849:	idr_destroy(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c-1850-}
--
net/bluetooth/hci_core.c=1855=void hci_free_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
--
net/bluetooth/hci_core.c-1868-	if (monitor->handle)
net/bluetooth/hci_core.c:1869:		idr_remove(&hdev->adv_monitors_idr, monitor->handle);
net/bluetooth/hci_core.c-1870-
--
net/bluetooth/hci_core.c=1881=int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
--
net/bluetooth/hci_core.c-1892-	max = HCI_MIN_ADV_MONITOR_HANDLE + HCI_MAX_ADV_MONITOR_NUM_HANDLES;
net/bluetooth/hci_core.c:1893:	handle = idr_alloc(&hdev->adv_monitors_idr, monitor, min, max,
net/bluetooth/hci_core.c-1894-			   GFP_KERNEL);
--
net/bluetooth/hci_core.c=1963=int hci_remove_single_adv_monitor(struct hci_dev *hdev, u16 handle)
net/bluetooth/hci_core.c-1964-{
net/bluetooth/hci_core.c:1965:	struct adv_monitor *monitor = idr_find(&hdev->adv_monitors_idr, handle);
net/bluetooth/hci_core.c-1966-
--
net/bluetooth/hci_core.c=1974=int hci_remove_all_adv_monitor(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-1980-	while (1) {
net/bluetooth/hci_core.c:1981:		monitor = idr_get_next(&hdev->adv_monitors_idr, &idr_next_id);
net/bluetooth/hci_core.c-1982-		if (!monitor)
--
net/bluetooth/hci_core.c=1996=bool hci_is_adv_monitoring(struct hci_dev *hdev)
net/bluetooth/hci_core.c-1997-{
net/bluetooth/hci_core.c:1998:	return !idr_is_empty(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c-1999-}
--
net/bluetooth/hci_core.c=2545=int hci_register_dev(struct hci_dev *hdev)
--
net/bluetooth/hci_core.c-2633-
net/bluetooth/hci_core.c:2634:	idr_init(&hdev->adv_monitors_idr);
net/bluetooth/hci_core.c-2635-	msft_register(hdev);
--
net/bluetooth/hci_event.c=6174=static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
--
net/bluetooth/hci_event.c-6300-					       bdaddr, bdaddr_type) &&
net/bluetooth/hci_event.c:6301:		    idr_is_empty(&hdev->adv_monitors_idr))
net/bluetooth/hci_event.c-6302-			return;
--
net/bluetooth/hci_sync.c=2840=static u8 hci_update_accept_list_sync(struct hci_dev *hdev)
--
net/bluetooth/hci_sync.c-2994-	 */
net/bluetooth/hci_sync.c:2995:	if (!idr_is_empty(&hdev->adv_monitors_idr) && !hdev->suspended &&
net/bluetooth/hci_sync.c-2996-	    hci_get_adv_monitor_offload_ext(hdev) == HCI_ADV_MONITOR_EXT_NONE &&
--
net/bluetooth/mgmt.c=5362=static int read_adv_mon_features(struct sock *sk, struct hci_dev *hdev,
--
net/bluetooth/mgmt.c-5380-
net/bluetooth/mgmt.c:5381:	idr_for_each_entry(&hdev->adv_monitors_idr, monitor, handle)
net/bluetooth/mgmt.c-5382-		handles[num_handles++] = monitor->handle;
--
net/bluetooth/msft.c=449=int msft_suspend_sync(struct hci_dev *hdev)
--
net/bluetooth/msft.c-460-	while (1) {
net/bluetooth/msft.c:461:		monitor = idr_get_next(&hdev->adv_monitors_idr, &handle);
net/bluetooth/msft.c-462-		if (!monitor)
--
net/bluetooth/msft.c=582=static void reregister_monitor(struct hci_dev *hdev)
--
net/bluetooth/msft.c-593-	while (1) {
net/bluetooth/msft.c:594:		monitor = idr_get_next(&hdev->adv_monitors_idr, &handle);
net/bluetooth/msft.c-595-		if (!monitor)
--
net/bluetooth/msft.c=667=void msft_do_close(struct hci_dev *hdev)
--
net/bluetooth/msft.c-682-	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
net/bluetooth/msft.c:683:		monitor = idr_find(&hdev->adv_monitors_idr,
net/bluetooth/msft.c-684-				   handle_data->mgmt_handle);
]

gemini-3.7-flash

							input: 27360
							output: 38
							thoughts: 136
						

**My Line of Reasoning**

Okay, so I'm looking at this code and I see `idr_destroy(&hdev->adv_monitors_idr)` in `hci_adv_monitors_clear`. Right, and that's called from `hci_release_dev()`. And, as I recall, `msft_release(hdev)` is *also* called from `hci_release_dev()`. So far, so good – standard cleanup stuff.

But wait a minute… I need to confirm something. Where *exactly* is `adv_monitors_idr` initialized? I'm pretty sure it's in `hci_register_dev()`, right? Okay, so it’s registered as part of device setup.

But why isn't it initialized in `hci_alloc_dev_priv`? Wouldn't that be a more logical place? It's where the device private data is set up... something seems slightly off there.

Alright, time to pull up `hci_alloc_dev_priv`. I need to double-check that this is how things are structured. Let's head over to `net/bluetooth/hci_core.c` and take a look at the code. This is a potential bug I need to confirm.

map[File:net/bluetooth/hci_core.c FirstLine:2450 LineCount:60]

map[Contents:2450:		hdev->le_conn_min_interval = 0x0018;
2451:		hdev->le_conn_max_interval = 0x0028;
2452:		hdev->le_conn_latency = 0x0000;
2453:		hdev->le_supv_timeout = 0x002a;
2454:		hdev->le_def_tx_len = 0x001b;
2455:		hdev->le_def_tx_time = 0x0148;
2456:		hdev->le_max_tx_len = 0x001b;
2457:		hdev->le_max_tx_time = 0x0148;
2458:		hdev->le_max_rx_len = 0x001b;
2459:		hdev->le_max_rx_time = 0x0148;
2460:		hdev->le_max_key_size = SMP_MAX_ENC_KEY_SIZE;
2461:		hdev->le_min_key_size = SMP_MIN_ENC_KEY_SIZE;
2462:		hdev->le_tx_def_phys = HCI_LE_SET_PHY_1M;
2463:		hdev->le_rx_def_phys = HCI_LE_SET_PHY_1M;
2464:		hdev->le_num_of_adv_sets = HCI_MAX_ADV_INSTANCES;
2465:		hdev->def_multi_adv_rotation_duration = HCI_DEFAULT_ADV_DURATION;
2466:		hdev->def_le_autoconnect_timeout = HCI_LE_CONN_TIMEOUT;
2467:		hdev->min_le_tx_power = HCI_TX_POWER_INVALID;
2468:		hdev->max_le_tx_power = HCI_TX_POWER_INVALID;
2469:	
2470:		hdev->rpa_timeout = HCI_DEFAULT_RPA_TIMEOUT;
2471:		hdev->discov_interleaved_timeout = DISCOV_INTERLEAVED_TIMEOUT;
2472:		hdev->conn_info_min_age = DEFAULT_CONN_INFO_MIN_AGE;
2473:		hdev->conn_info_max_age = DEFAULT_CONN_INFO_MAX_AGE;
2474:		hdev->auth_payload_timeout = DEFAULT_AUTH_PAYLOAD_TIMEOUT;
2475:		hdev->min_enc_key_size = HCI_MIN_ENC_KEY_SIZE;
2476:	
2477:		/* default 1.28 sec page scan */
2478:		hdev->def_page_scan_type = PAGE_SCAN_TYPE_STANDARD;
2479:		hdev->def_page_scan_int = 0x0800;
2480:		hdev->def_page_scan_window = 0x0012;
2481:	
2482:		mutex_init(&hdev->lock);
2483:		mutex_init(&hdev->req_lock);
2484:		mutex_init(&hdev->mgmt_pending_lock);
2485:	
2486:		ida_init(&hdev->unset_handle_ida);
2487:	
2488:		INIT_LIST_HEAD(&hdev->mesh_pending);
2489:		INIT_LIST_HEAD(&hdev->mgmt_pending);
2490:		INIT_LIST_HEAD(&hdev->reject_list);
2491:		INIT_LIST_HEAD(&hdev->accept_list);
2492:		INIT_LIST_HEAD(&hdev->uuids);
2493:		INIT_LIST_HEAD(&hdev->link_keys);
2494:		INIT_LIST_HEAD(&hdev->long_term_keys);
2495:		INIT_LIST_HEAD(&hdev->identity_resolving_keys);
2496:		INIT_LIST_HEAD(&hdev->remote_oob_data);
2497:		INIT_LIST_HEAD(&hdev->le_accept_list);
2498:		INIT_LIST_HEAD(&hdev->le_resolv_list);
2499:		INIT_LIST_HEAD(&hdev->le_conn_params);
2500:		INIT_LIST_HEAD(&hdev->pend_le_conns);
2501:		INIT_LIST_HEAD(&hdev->pend_le_reports);
2502:		INIT_LIST_HEAD(&hdev->conn_hash.list);
2503:		INIT_LIST_HEAD(&hdev->adv_instances);
2504:		INIT_LIST_HEAD(&hdev->blocked_keys);
2505:		INIT_LIST_HEAD(&hdev->monitored_devices);
2506:	
2507:		INIT_LIST_HEAD(&hdev->local_codecs);
2508:		INIT_WORK(&hdev->rx_work, hci_rx_work);
2509:		INIT_WORK(&hdev->cmd_work, hci_cmd_work);
]

gemini-3.7-flash

							input: 29156
							output: 49
							thoughts: 2081
						

**Race Condition Analysis and Patch Assessment**

Okay, let's break this down. My initial thought was to review the initialization sequence in `hci_alloc_dev_priv`, but then I realized the critical initialization for the `adv_monitors_idr` and the `msft` data, happened in `hci_register_dev`. This made me question the original order: why weren't these crucial initializations done earlier, *before* queuing the work?

Specifically, in `hci_register_dev`, after the initial device event, hold, and suspend notifier registration, we have:

```c
	idr_init(&hdev->adv_monitors_idr);
	msft_register(hdev);
	queue_work(hdev->req_workqueue, &hdev->power_on);
	return id;
```

The key issue is `queue_work`. This schedules `hdev->power_on`, which, depending on the device's state (particularly if `HCI_UNCONFIGURED` or `HCI_QUIRK_RAW_DEVICE` is set), can lead to an early call to `hci_dev_do_close` which triggers `msft_do_close`.

Inside `msft_do_close`, we have:

```c
void msft_do_close(struct hci_dev *hdev)
{
	struct msft_data *msft = hdev->msft_data;
...
	if (!msft)
		return;
...
	mutex_lock(&msft->filter_lock);
```

The race is clear: Thread 1 (the `hci_register_dev` thread) queues the work, but Thread 2 (the workqueue) potentially starts executing `hci_power_on` before `msft` is *fully* initialized. `msft_register` does this:

```c
void msft_register(struct hci_dev *hdev)
{
...
	msft = kzalloc_obj(*msft);
	if (!msft) {
		bt_dev_err(hdev, "Failed to register MSFT extension");
		return;
	}

	INIT_LIST_HEAD(&msft->handle_map);
	INIT_LIST_HEAD(&msft->address_filters);
	hdev->msft_data = msft;
	mutex_init(&msft->filter_lock);
}
```

Thread 1 *writes* `hdev->msft_data = msft;`, but Thread 2 *reads* it before the `mutex_init` is called, meaning `msft->filter_lock` is uninitialized. This leads to the `DEBUG_LOCKS_WARN_ON` trigger due to accessing an uninitialized mutex. Additionally, if the workqueue thread executed even *earlier*, it could touch the uninitialized `adv_monitors_idr`.

Now, looking at the patch, it cleverly reorders the operations. The changes are straightforward. In `hci_register_dev`, it moves the `queue_work` *after* the initializations:

```c
	idr_init(&hdev->adv_monitors_idr);
	msft_register(hdev);
	queue_work(hdev->req_workqueue, &hdev->power_on);
```

And critically, inside `msft_register`:

```c
	INIT_LIST_HEAD(&msft->handle_map);
	INIT_LIST_HEAD(&msft->address_filters);
	mutex_init(&msft->filter_lock);
	hdev->msft_data = msft;
```

This *guarantees* that `adv_monitors_idr` and `msft_data` are properly initialized before the asynchronous work is scheduled. The `hdev->msft_data = msft;` assignment, which publishes the data, is now *after* `mutex_init`.

This adheres to kernel guidelines.  Specifically:

1.  We have moved the initialization of critical data *before* the asynchronous work is started.
2.  Inside `msft_register`, we have fully initialized `struct msft_data` (including `mutex_init`) before the pointer `hdev->msft_data = msft;` is published.

I note that the patch *doesn't* add explicit null checks or sentinels in `msft_do_close` to account for this potential race, *because the race is now eliminated*. Instead, the fix relies on enforcing the correct initialization order to prevent the race from occurring in the first place.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:5 Name:msft_register SourceTreePrefix:]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_register_dev SourceFile:net/bluetooth/hci_core.c SourceLine:2635 SourceSnippet:2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
]] TruncatedOutput:false]

gemini-3.7-flash

							input: 32547
							output: 49
							thoughts: 12
						

Here's my take on those thoughts:

**Checking `msft_release` References**

Alright, time to get down to brass tacks. I need to make sure I haven't overlooked any instances where I'm referencing this `msft_release` object or variable. It's crucial for maintaining code clarity and avoiding unexpected behavior, especially in a project of this scale. I'll need to go beyond a simple search, though; I should keep an eye out for how it's being *used*. Are there any assignments? Are there any indirect dependencies? What kinds of operations are being performed on it? Are there any potential naming collisions, even subtle ones? I want to confirm that all of its uses are consistent, intentional, and documented. This includes scrutinizing any external libraries or modules that might interact with it. No stone unturned.

map[ContextFile:net/bluetooth/msft.c IncludeSnippetLines:5 Name:msft_release SourceTreePrefix:]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hci_release_dev SourceFile:net/bluetooth/hci_core.c SourceLine:2731 SourceSnippet:2726:		hci_bdaddr_list_clear(&hdev->le_resolv_list);
2727:		hci_conn_params_clear_all(hdev);
2728:		hci_discovery_filter_clear(hdev);
2729:		hci_blocked_keys_clear(hdev);
2730:		hci_codec_list_clear(&hdev->local_codecs);
2731:		msft_release(hdev);
2732:		hci_dev_unlock(hdev);
2733:	
2734:		ida_destroy(&hdev->unset_handle_ida);
2735:		ida_free(&hci_index_ida, hdev->id);
2736:		kfree_skb(hdev->sent_cmd);
]] TruncatedOutput:false]

gemini-3.7-flash

							input: 33070
							output: 56
							thoughts: 22
						

**Checking for `msft_data` Usage in `net/bluetooth`**

Okay, so I need to see if `msft_data` is used anywhere else within the `net/bluetooth` directory. It's a pretty straightforward task. I'll need to use some form of search tool – likely `grep` or a similar utility – and specify the directory and the search term. I need to be precise, though. I want to make sure I don't accidentally pick up false positives. I might need to refine the search parameters to be more targeted, like searching for the exact variable name or function call where `msft_data` might be used. I should also consider how the code is structured in that area. Are there specific modules or files where it's more likely to appear? Knowing the general architecture will help me focus my search and speed things up. Let's get started.

map[ContextFile:include/net/bluetooth/hci_core.h IncludeSnippetLines:5 Name:hci_dev::msft_data SourceTreePrefix:]

map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_add_address_filter SourceFile:net/bluetooth/msft.c SourceLine:932 SourceSnippet: 927:	static struct msft_monitor_addr_filter_data *msft_add_address_filter
 928:			(struct hci_dev *hdev, u8 addr_type, bdaddr_t *bdaddr,
 929:			 struct msft_monitor_advertisement_handle_data *handle_data)
 930:	{
 931:		struct msft_monitor_addr_filter_data *address_filter = NULL;
 932:		struct msft_data *msft = hdev->msft_data;
 933:		int err;
 934:	
 935:		address_filter = kzalloc_obj(*address_filter);
 936:		if (!address_filter)
 937:			return NULL;
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_add_address_filter_sync SourceFile:net/bluetooth/msft.c SourceLine:838 SourceSnippet: 833:	static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
 834:	{
 835:		struct msft_monitor_addr_filter_data *address_filter = data;
 836:		struct msft_rp_le_monitor_advertisement *rp;
 837:		struct msft_cp_le_monitor_advertisement *cp;
 838:		struct msft_data *msft = hdev->msft_data;
 839:		struct sk_buff *skb = NULL;
 840:		bool remove = false;
 841:		size_t size;
 842:	
 843:		if (!msft) {
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_add_monitor_pattern SourceFile:net/bluetooth/msft.c SourceLine:1154 SourceSnippet:1151:	/* This function requires the caller holds hci_req_sync_lock */
1152:	int msft_add_monitor_pattern(struct hci_dev *hdev, struct adv_monitor *monitor)
1153:	{
1154:		struct msft_data *msft = hdev->msft_data;
1155:	
1156:		if (!msft)
1157:			return -EOPNOTSUPP;
1158:	
1159:		if (msft->resuming || msft->suspending)
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_cancel_address_filter_sync SourceFile:net/bluetooth/msft.c SourceLine:714 SourceSnippet: 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
 715:		struct sk_buff *skb;
 716:		int err = 0;
 717:	
 718:		if (!msft) {
 719:			bt_dev_err(hdev, "MSFT: msft data is freed");
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_do_close SourceFile:net/bluetooth/msft.c SourceLine:669 SourceSnippet: 667:	void msft_do_close(struct hci_dev *hdev)
 668:	{
 669:		struct msft_data *msft = hdev->msft_data;
 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_do_open SourceFile:net/bluetooth/msft.c SourceLine:633 SourceSnippet: 630:	/* This function requires the caller holds hci_req_sync_lock */
 631:	void msft_do_open(struct hci_dev *hdev)
 632:	{
 633:		struct msft_data *msft = hdev->msft_data;
 634:	
 635:		if (hdev->msft_opcode == HCI_OP_NOP)
 636:			return;
 637:	
 638:		if (!msft) {
] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:msft_do_open SourceFile:net/bluetooth/msft.c SourceLine:652 SourceSnippet: 647:		msft->evt_prefix = NULL;
 648:		msft->evt_prefix_len = 0;
 649:		msft->features = 0;
 650:	
 651:		if (!read_supported_features(hdev, msft)) {
 652:			hdev->msft_data = NULL;
 653:			kfree(msft);
 654:			return;
 655:		}
 656:	
 657:		if (msft_monitor_supported(hdev)) {
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_find_address_data SourceFile:net/bluetooth/msft.c SourceLine:215 SourceSnippet: 210:	static struct msft_monitor_addr_filter_data *msft_find_address_data
 211:				(struct hci_dev *hdev, u8 addr_type, bdaddr_t *addr,
 212:				 u8 pattern_handle)
 213:	{
 214:		struct msft_monitor_addr_filter_data *entry;
 215:		struct msft_data *msft = hdev->msft_data;
 216:	
 217:		list_for_each_entry(entry, &msft->address_filters, list) {
 218:			if (entry->pattern_handle == pattern_handle &&
 219:			    addr_type == entry->addr_type &&
 220:			    !bacmp(addr, &entry->bdaddr))
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_find_handle_data SourceFile:net/bluetooth/msft.c SourceLine:197 SourceSnippet: 192:	 */
 193:	static struct msft_monitor_advertisement_handle_data *msft_find_handle_data
 194:					(struct hci_dev *hdev, u16 handle, bool is_mgmt)
 195:	{
 196:		struct msft_monitor_advertisement_handle_data *entry;
 197:		struct msft_data *msft = hdev->msft_data;
 198:	
 199:		list_for_each_entry(entry, &msft->handle_map, list) {
 200:			if (is_mgmt && entry->mgmt_handle == handle)
 201:				return entry;
 202:			if (!is_mgmt && entry->msft_handle == handle)
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_get_features SourceFile:net/bluetooth/msft.c SourceLine:1118 SourceSnippet:1116:	__u64 msft_get_features(struct hci_dev *hdev)
1117:	{
1118:		struct msft_data *msft = hdev->msft_data;
1119:	
1120:		return msft ? msft->features : 0;
1121:	}
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_le_cancel_monitor_advertisement_cb SourceFile:net/bluetooth/msft.c SourceLine:373 SourceSnippet: 368:							   struct adv_monitor *monitor,
 369:							   struct sk_buff *skb)
 370:	{
 371:		struct msft_rp_le_cancel_monitor_advertisement *rp;
 372:		struct msft_monitor_advertisement_handle_data *handle_data;
 373:		struct msft_data *msft = hdev->msft_data;
 374:		int status = 0;
 375:		u8 msft_handle;
 376:	
 377:		rp = (struct msft_rp_le_cancel_monitor_advertisement *)skb->data;
 378:		if (skb->len < sizeof(*rp)) {
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_le_monitor_advertisement_cb SourceFile:net/bluetooth/msft.c SourceLine:264 SourceSnippet: 259:						    struct adv_monitor *monitor,
 260:						    struct sk_buff *skb)
 261:	{
 262:		struct msft_rp_le_monitor_advertisement *rp;
 263:		struct msft_monitor_advertisement_handle_data *handle_data;
 264:		struct msft_data *msft = hdev->msft_data;
 265:		int status = 0;
 266:	
 267:		hci_dev_lock(hdev);
 268:	
 269:		rp = (struct msft_rp_le_monitor_advertisement *)skb->data;
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_le_set_advertisement_filter_enable_cb SourceFile:net/bluetooth/msft.c SourceLine:1128 SourceSnippet:1123:	static void msft_le_set_advertisement_filter_enable_cb(struct hci_dev *hdev,
1124:							       void *user_data,
1125:							       u8 status)
1126:	{
1127:		struct msft_cp_le_set_advertisement_filter_enable *cp = user_data;
1128:		struct msft_data *msft = hdev->msft_data;
1129:	
1130:		/* Error 0x0C would be returned if the filter enabled status is
1131:		 * already set to whatever we were trying to set.
1132:		 * Although the default state should be disabled, some controller set
1133:		 * the initial value to enabled. Because there is no way to know the
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_monitor_device_evt SourceFile:net/bluetooth/msft.c SourceLine:977 SourceSnippet: 972:	static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 973:	{
 974:		struct msft_monitor_addr_filter_data *n, *address_filter = NULL;
 975:		struct msft_ev_le_monitor_device *ev;
 976:		struct msft_monitor_advertisement_handle_data *handle_data;
 977:		struct msft_data *msft = hdev->msft_data;
 978:		u16 mgmt_handle = 0xffff;
 979:		u8 addr_type;
 980:	
 981:		ev = msft_skb_pull(hdev, skb, MSFT_EV_LE_MONITOR_DEVICE, sizeof(*ev));
 982:		if (!ev)
] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:msft_register SourceFile:net/bluetooth/msft.c SourceLine:767 SourceSnippet: 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_release SourceFile:net/bluetooth/msft.c SourceLine:773 SourceSnippet: 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:msft_release SourceFile:net/bluetooth/msft.c SourceLine:780 SourceSnippet: 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
 780:		hdev->msft_data = NULL;
 781:	
 782:		kfree(msft->evt_prefix);
 783:		mutex_destroy(&msft->filter_lock);
 784:		kfree(msft);
 785:	}
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_remove_addr_filters_sync SourceFile:net/bluetooth/msft.c SourceLine:307 SourceSnippet: 302:	/* This function requires the caller holds hci_req_sync_lock */
 303:	static void msft_remove_addr_filters_sync(struct hci_dev *hdev, u8 handle)
 304:	{
 305:		struct msft_monitor_addr_filter_data *address_filter, *n;
 306:		struct msft_cp_le_cancel_monitor_advertisement cp;
 307:		struct msft_data *msft = hdev->msft_data;
 308:		struct list_head head;
 309:		struct sk_buff *skb;
 310:	
 311:		INIT_LIST_HEAD(&head);
 312:	
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_remove_monitor SourceFile:net/bluetooth/msft.c SourceLine:1168 SourceSnippet:1165:	/* This function requires the caller holds hci_req_sync_lock */
1166:	int msft_remove_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
1167:	{
1168:		struct msft_data *msft = hdev->msft_data;
1169:	
1170:		if (!msft)
1171:			return -EOPNOTSUPP;
1172:	
1173:		if (msft->resuming || msft->suspending)
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_resume_sync SourceFile:net/bluetooth/msft.c SourceLine:610 SourceSnippet: 607:	/* This function requires the caller holds hci_req_sync_lock */
 608:	int msft_resume_sync(struct hci_dev *hdev)
 609:	{
 610:		struct msft_data *msft = hdev->msft_data;
 611:	
 612:		if (!msft || !msft_monitor_supported(hdev))
 613:			return 0;
 614:	
 615:		hci_dev_lock(hdev);
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_set_filter_enable SourceFile:net/bluetooth/msft.c SourceLine:1182 SourceSnippet:1179:	int msft_set_filter_enable(struct hci_dev *hdev, bool enable)
1180:	{
1181:		struct msft_cp_le_set_advertisement_filter_enable cp;
1182:		struct msft_data *msft = hdev->msft_data;
1183:		int err;
1184:	
1185:		if (!msft)
1186:			return -EOPNOTSUPP;
1187:	
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_suspend_sync SourceFile:net/bluetooth/msft.c SourceLine:451 SourceSnippet: 448:	/* This function requires the caller holds hci_req_sync_lock */
 449:	int msft_suspend_sync(struct hci_dev *hdev)
 450:	{
 451:		struct msft_data *msft = hdev->msft_data;
 452:		struct adv_monitor *monitor;
 453:		int handle = 0;
 454:	
 455:		if (!msft || !msft_monitor_supported(hdev))
 456:			return 0;
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:msft_vendor_evt SourceFile:net/bluetooth/msft.c SourceLine:1070 SourceSnippet:1068:	void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
1069:	{
1070:		struct msft_data *msft = hdev->msft_data;
1071:		u8 *evt_prefix;
1072:		u8 *evt;
1073:	
1074:		if (!msft)
1075:			return;
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:reregister_monitor SourceFile:net/bluetooth/msft.c SourceLine:585 SourceSnippet: 581:	/* This function requires the caller holds hci_req_sync_lock */
 582:	static void reregister_monitor(struct hci_dev *hdev)
 583:	{
 584:		struct adv_monitor *monitor;
 585:		struct msft_data *msft = hdev->msft_data;
 586:		int handle = 0;
 587:	
 588:		if (!msft)
 589:			return;
 590:	
]] TruncatedOutput:false]

gemini-3.7-flash

							input: 38630
							output: 19
							thoughts: 1377
						

**Analyzing a Bluetooth Driver Patch: A Deep Dive**

Okay, let's break this down. My initial thought was to examine `msft_do_open` in `net/bluetooth/msft.c`. I wanted to understand how it handles Microsoft-specific extensions. I was particularly interested in what happened if `read_supported_features` failed, and whether there was any potential for resource leaks or uninitialized data access.  I noted that the code carefully frees and nulls out the `msft->evt_prefix` and sets `hdev->msft_data = NULL;` when `read_supported_features` fails, and `msft_release` does nothing if `hdev->msft_data` is NULL.

Then, I looked at the proposed changes, specifically in `hci_register_dev`. The critical part here was the reordering of `queue_work(hdev->req_workqueue, &hdev->power_on)`.  Originally, it was called *before* initializing `hdev->adv_monitors_idr` and before `msft_register(hdev)`.  I realized this could create a race condition. `power_on` runs asynchronously and may call `hci_dev_do_close()`, which in turn, could call `msft_do_close()`. `msft_do_close` accesses `hdev->adv_monitors_idr` and `hdev->msft_data`, potentially *before* they are fully initialized. Moving `queue_work` *after* those initializations ensures that the device is fully set up before `power_on` starts. This is a fundamental kernel best practice.

Next, I scrutinized the changes within `msft_register`.  The reordering of `hdev->msft_data = msft;` *after* the `mutex_init(&msft->filter_lock);` was crucial. This guarantees that `hdev->msft_data` is only exposed *after* all its fields, including the mutex and linked lists, are fully initialized. This prevents any potential read before initialization issues.

I then ran through the checklist. This patch is standalone and touches only two files in `net/bluetooth/`. Its root cause is definitively a race condition that it directly and elegantly fixes. The patch doesn't add any band-aids like extra null checks (which would be a symptom of not addressing the root problem) or anything like that, which I would be watching for. It fixes the root cause directly by reordering initialization and workqueuing. It also ensures the correct lifecycle symmetry and typestate soundness by initializing everything before publishing it. I didn't see any memory leaks or concurrency bugs, either.

Finally, I double-checked the changes. Both modifications in the two files compile cleanly, conceptually, and are safe. They're straightforward and follow kernel best practices. This is a clean, elegant fix that directly addresses the architectural root cause.

Therefore, I'm calling it with ReviewApproved: true. No comments needed.

map[ReviewApproved:true ReviewComments:[]]

map[ReviewApproved:true ReviewComments:[]]

map[NeedsIteration:false ReviewFeedback:]

map[]

map[StyleItems:<nil>]

map[CheckpatchOutput:total: 0 errors, 0 warnings, 0 checks, 22 lines checked

Your patch has no obvious style problems and is ready for submission.
]

core

map[ActionableIssues:[]]

You are an expert Linux kernel maintainer acting as a code style arbiter.
Your task is to review scripts/checkpatch.pl output and reviewer style requests for a proposed patch.

Determine which reported issues are genuine, actionable formatting/style defects (e.g. indentation, whitespace,
naming, syntax style) and should be fixed. List them in ActionableIssues.

Ignore issues that are false positives, intentional constructs (e.g. BUG_ON/XA_BUG_ON in test files, macros,
subsystem conventions), or unfixable without breaking code logic or tests. If no issues should be changed,
leave ActionableIssues empty.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

The patch diff is:

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)



The checkpatch.pl output is:
total: 0 errors, 0 warnings, 0 checks, 22 lines checked

Your patch has no obvious style problems and is ready for submission.







Carefully evaluate each issue and populate ActionableIssues.

gemini-3.7-flash

							input: 805
							output: 15
							thoughts: 161
						

**Patch Review: HCI Core and MSFT Module**

Okay, so I've just been looking over this patch. It's a pretty straightforward rearrangement of some initialization steps within the Bluetooth HCI core and the MSFT module. Specifically, it looks like `queue_work()` for the power-on workqueue is being moved after the `msft_register(hdev)` call in `hci_core.c`. Then, in `msft.c`, the assignment of `hdev->msft_data = msft;` is being moved after the `mutex_init(&msft->filter_lock);` call.

The `checkpatch` report is clean – no errors, no warnings, and all the lines have been checked. That's always a good sign. Looks like the style is pristine; nothing sticks out. I then went through the diff itself, double-checking for any style violations or potential issues that `checkpatch` might have missed, and I'm not seeing anything of concern. No reviewer comments, either.

Based on this quick analysis, there's nothing immediately jumping out as problematic. ActionableIssues is empty, which confirms my initial impression. The patch is clean and follows kernel style, it's ready for submission.

map[ActionableIssues:[]]

map[ActionableIssues:[]]

map[NeedRefinement:false]

map[NeedRefinement:false]

core

map[FixesHash:9e14606d8f38ea52a38c27692a9c1513c987a5da]

You are an experienced Linux kernel developer tasked with identifying the commit
that introduced the bug being fixed. Identifying the correct buggy commit is crucial
for proper kernel maintenance (backporting to stable trees, etc.).

Your investigation strategy:
1. Examine the patch that fixes the bug. Use git tools (like git-log or git-blame)
   to trace the history of the lines or functions modified by the patch.
2. Analyze the stack trace in the crash report. Identify the key files and functions
   involved in the crash and investigate their history to see when the problematic
   logic was introduced.
3. Compare the bug explanation with the commit history to find the point where
   the described logic error first appeared.

A bug is typically introduced when a piece of code is first written, or when
a refactoring changed its logic in a way that introduced the bug.
Trace the history of relevant symbols or find when specific code patterns were introduced/removed.

You must provide exactly one bug-introducing commit hash.
If you are unable to confidently determine the bug-introducing commit after investigation,
return an empty string rather than guessing.

Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

The crash is:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf



The explanation of the root cause is:

This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```


The patch that fixes the bug is:

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)


Search for the commit(s) that introduced this bug.

gemini-3.7-flash

							input: 7335
							output: 75
							thoughts: 81
						

Okay, here's my interpretation of this debugging process, summarized as my own thought process:

**Hunting Down the Bug's Origin**

Right, so I've been given a crash report, a breakdown of what's gone wrong, and a patch that (hopefully!) fixes the issue. Now comes the crucial step: figuring out *how* this bug made its way into the system. This is a classic "find the needle in the haystack" situation, but thankfully, we have tools to help.

The user's clearly providing evidence and details, so now it's my task to find the root cause, and where this bug originated.

My first thought is to dive into the Git history. Given the files mentioned – `net/bluetooth/msft.c` and `net/bluetooth/hci_core.c` – I'll start by focusing on those. I'll need to use either `git log` or `git blame` on these files. I can visualize which tool would be most effective by considering the nature of the change - `git blame` is perfect for finding the exact commit that introduced a specific line, while `git log` is better for understanding the broader history of changes in a file, in case the bug is related to a more significant modification.

So, I'll go ahead and call `git log` or `git blame` on those files and see what the output tells me. Hopefully, this will lead me to the culprit!

map[End:775 File:net/bluetooth/msft.c Start:755]

map[Output:5031ffcc79b81 755) 	struct msft_data *msft = NULL;
5031ffcc79b81 756) 
5031ffcc79b81 757) 	bt_dev_dbg(hdev, "Register MSFT extension");
5031ffcc79b81 758) 
bf4afc53b77ae 759) 	msft = kzalloc_obj(*msft);
5031ffcc79b81 760) 	if (!msft) {
5031ffcc79b81 761) 		bt_dev_err(hdev, "Failed to register MSFT extension");
5031ffcc79b81 762) 		return;
5031ffcc79b81 763) 	}
5031ffcc79b81 764) 
5031ffcc79b81 765) 	INIT_LIST_HEAD(&msft->handle_map);
9e14606d8f38e 766) 	INIT_LIST_HEAD(&msft->address_filters);
5031ffcc79b81 767) 	hdev->msft_data = msft;
9e14606d8f38e 768) 	mutex_init(&msft->filter_lock);
5031ffcc79b81 769) }
5031ffcc79b81 770) 
10f9f426ac6e7 771) void msft_release(struct hci_dev *hdev)
5031ffcc79b81 772) {
5031ffcc79b81 773) 	struct msft_data *msft = hdev->msft_data;
5031ffcc79b81 774) 
5031ffcc79b81 775) 	if (!msft)
]

map[End:2645 File:net/bluetooth/hci_core.c Start:2620]

map[Output:fe92ee6425a2c 2620) 	 * callback.
fe92ee6425a2c 2621) 	 */
fe92ee6425a2c 2622) 	if (hdev->wakeup)
e1cff7002b716 2623) 		hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
fe92ee6425a2c 2624) 
05fcd4c4f1011 2625) 	hci_sock_dev_event(hdev, HCI_DEV_REG);
dc946bd86f725 2626) 	hci_dev_hold(hdev);
^1da177e4c3f4 2627) 
9111786492f13 2628) 	error = hci_register_suspend_notifier(hdev);
9111786492f13 2629) 	if (error)
0d75da38e060d 2630) 		BT_WARN("register suspend notifier failed error:%d\n", error);
9952d90ea2885 2631) 
1920257316615 2632) 	queue_work(hdev->req_workqueue, &hdev->power_on);
fbe96d6ff9f4e 2633) 
e5e1e7fd470cc 2634) 	idr_init(&hdev->adv_monitors_idr);
5031ffcc79b81 2635) 	msft_register(hdev);
e5e1e7fd470cc 2636) 
^1da177e4c3f4 2637) 	return id;
f48fd9c8cd746 2638) 
33ca954daf1ac 2639) err_wqueue:
5a4bb6a8e981d 2640) 	debugfs_remove_recursive(hdev->debugfs);
33ca954daf1ac 2641) 	destroy_workqueue(hdev->workqueue);
6ead1bbc381a6 2642) 	destroy_workqueue(hdev->req_workqueue);
33ca954daf1ac 2643) err:
9c16d0c8d93e3 2644) 	ida_free(&hci_index_ida, hdev->id);
f48fd9c8cd746 2645) 
]

gemini-3.7-flash

							input: 9080
							output: 54
							thoughts: 143
						

**Analyzing Recent Bluetooth Driver Commits**

Okay, let's dive in. I need to get a handle on the recent changes in the Bluetooth driver, specifically the Microsoft-related code. I see four commits in `net/bluetooth/msft.c` that look relevant. First, there's `5031ffcc79b81`, which mentions Microsoft vendor extension support. That's interesting; I'll want to see how they're handling vendor-specific commands and data structures. Then, `9e14606d8f38e` introduces monitor device support. This sounds like it could be useful for debugging or performance analysis. Next, `e5e1e7fd470cc` adds an advertising monitor list and associated APIs, which is definitely worth a closer look; I'm curious about the implementation details and how they're handling potentially large lists. Finally, `1920257316615` appears to address a bug related to power-on work queueing. That's a good find, as it suggests a potential race condition or resource management issue.

Now, I'll use `git show` to examine each of these commits in detail, starting with the oldest. I'll need to pay close attention to the code changes, commit messages, and any relevant documentation to understand the rationale behind each modification and assess its impact on the driver's overall stability, performance, and security. I'll be looking for potential regressions, areas for optimization, or architectural implications that might affect my own work.

map[Commit:5031ffcc79b81]

map[Output:commit 5031ffcc79b81776ac8f7f8b1a585aed8818e3d1
Author: Miao-chen Chou <mcchou@chromium.org>
Date:   Thu Sep 9 14:10:23 2021 -0700

    Bluetooth: Keep MSFT ext info throughout a hci_dev's life cycle
    
    This splits the msft_do_{open/close} to msft_do_{open/close} and
    msft_{register/unregister}. With this change it is possible to retain
    the MSFT extension info irrespective of controller power on/off state.
    This helps bluetoothd to report correct 'supported features' of the
    controller to the D-Bus clients event if the controller is off. It also
    re-reads the MSFT info upon every msft_do_open().
    
    The following test steps were performed.
    1. Boot the test device and verify the MSFT support debug log in syslog.
    2. Power off the controller and read the 'supported features', power on
       and read again.
    3. Restart the bluetoothd and verify the 'supported features' value.
    
    Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Reviewed-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Alain Michaud <alainm@chromium.org>
    Signed-off-by: Manish Mandlik <mmandlik@google.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5236faa397fa..beda5dac1658 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3990,6 +3990,7 @@ int hci_register_dev(struct hci_dev *hdev)
 	queue_work(hdev->req_workqueue, &hdev->power_on);
 
 	idr_init(&hdev->adv_monitors_idr);
+	msft_register(hdev);
 
 	return id;
 
@@ -4022,6 +4023,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
 		cancel_work_sync(&hdev->suspend_prepare);
 	}
 
+	msft_unregister(hdev);
+
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index b4bfae41e8a5..21b1787e7893 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -184,28 +184,36 @@ static void reregister_monitor_on_restart(struct hci_dev *hdev, int handle)
 
 void msft_do_open(struct hci_dev *hdev)
 {
-	struct msft_data *msft;
+	struct msft_data *msft = hdev->msft_data;
 
 	if (hdev->msft_opcode == HCI_OP_NOP)
 		return;
 
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT extension not registered");
+		return;
+	}
+
 	bt_dev_dbg(hdev, "Initialize MSFT extension");
 
-	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
-	if (!msft)
-		return;
+	/* Reset existing MSFT data before re-reading */
+	kfree(msft->evt_prefix);
+	msft->evt_prefix = NULL;
+	msft->evt_prefix_len = 0;
+	msft->features = 0;
 
 	if (!read_supported_features(hdev, msft)) {
+		hdev->msft_data = NULL;
 		kfree(msft);
 		return;
 	}
 
-	INIT_LIST_HEAD(&msft->handle_map);
-	hdev->msft_data = msft;
-
 	if (msft_monitor_supported(hdev)) {
 		msft->reregistering = true;
 		msft_set_filter_enable(hdev, true);
+		/* Monitors get removed on power off, so we need to explicitly
+		 * tell the controller to re-monitor.
+		 */
 		reregister_monitor_on_restart(hdev, 0);
 	}
 }
@@ -221,8 +229,9 @@ void msft_do_close(struct hci_dev *hdev)
 
 	bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 
-	hdev->msft_data = NULL;
-
+	/* The controller will silently remove all monitors on power off.
+	 * Therefore, remove handle_data mapping and reset monitor state.
+	 */
 	list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 		monitor = idr_find(&hdev->adv_monitors_idr,
 				   handle_data->mgmt_handle);
@@ -233,6 +242,34 @@ void msft_do_close(struct hci_dev *hdev)
 		list_del(&handle_data->list);
 		kfree(handle_data);
 	}
+}
+
+void msft_register(struct hci_dev *hdev)
+{
+	struct msft_data *msft = NULL;
+
+	bt_dev_dbg(hdev, "Register MSFT extension");
+
+	msft = kzalloc(sizeof(*msft), GFP_KERNEL);
+	if (!msft) {
+		bt_dev_err(hdev, "Failed to register MSFT extension");
+		return;
+	}
+
+	INIT_LIST_HEAD(&msft->handle_map);
+	hdev->msft_data = msft;
+}
+
+void msft_unregister(struct hci_dev *hdev)
+{
+	struct msft_data *msft = hdev->msft_data;
+
+	if (!msft)
+		return;
+
+	bt_dev_dbg(hdev, "Unregister MSFT extension");
+
+	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
 	kfree(msft);
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 6e56d94b88d8..8018948c5975 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -13,6 +13,8 @@
 #if IS_ENABLED(CONFIG_BT_MSFTEXT)
 
 bool msft_monitor_supported(struct hci_dev *hdev);
+void msft_register(struct hci_dev *hdev);
+void msft_unregister(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb);
@@ -31,6 +33,8 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 	return false;
 }
 
+static inline void msft_register(struct hci_dev *hdev) {}
+static inline void msft_unregister(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb) {}
]

map[Commit:9e14606d8f38e]

map[Output:commit 9e14606d8f38ea52a38c27692a9c1513c987a5da
Author: Hilda Wu <hildawu@realtek.com>
Date:   Wed Jun 21 18:00:31 2023 +0800

    Bluetooth: msft: Extended monitor tracking by address filter
    
    Since limited tracking device per condition, this feature is to support
    tracking multiple devices concurrently.
    When a pattern monitor detects the device, this feature issues an address
    monitor for tracking that device. Let pattern monitor can keep monitor
    new devices.
    This feature adds an address filter when receiving a LE monitor device
    event which monitor handle is for a pattern, and the controller started
    monitoring the device. And this feature also has cancelled the monitor
    advertisement from address filters when receiving a LE monitor device
    event when the controller stopped monitoring the device specified by an
    address and monitor handle.
    
    Below is an example to know the feature adds the address filter.
    
    //Add MSFT pattern monitor
    < HCI Command: Vendor (0x3f|0x00f0) plen 14          #142 [hci0] 55.552420
            03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
    > HCI Event: Command Complete (0x0e) plen 6          #143 [hci0] 55.653960
          Vendor (0x3f|0x00f0) ncmd 2
            Status: Success (0x00)
            03 00
    
    //Got event from the pattern monitor
    > HCI Event: Vendor (0xff) plen 18                   #148 [hci0] 58.384953
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            00 01                                            ..
    
    //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
    < HCI Command: Vendor (0x3f|0x00f0) plen 13          #149 [hci0] 58.385067
            03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.
    
    //Report to userspace about found device (ADV Monitor Device Found)
    @ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
            01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
            0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
            c1 03 03 03 12 18                                ......
    
    //Got event from address monitor
    > HCI Event: Vendor (0xff) plen 18                   #152 [hci0] 58.672956
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            01 01
    
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Hilda Wu <hildawu@realtek.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 04399b3c39a0..ddae6524106d 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -1269,6 +1269,10 @@ void btrtl_set_quirks(struct hci_dev *hdev, struct btrtl_device_info *btrtl_dev)
 		if (btrtl_dev->project_id == CHIP_ID_8852C)
 			btrealtek_set_flag(hdev, REALTEK_ALT6_CONTINUOUS_TX_CHIP);
 
+		if (btrtl_dev->project_id == CHIP_ID_8852A ||
+		    btrtl_dev->project_id == CHIP_ID_8852C)
+			set_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks);
+
 		hci_set_aosp_capable(hdev);
 		break;
 	default:
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ab2f8f1817cf..5723405b833e 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -309,6 +309,16 @@ enum {
 	 * to support it.
 	 */
 	HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT,
+
+	/* When this quirk is set, MSFT extension monitor tracking by
+	 * address filter is supported. Since tracking quantity of each
+	 * pattern is limited, this feature supports tracking multiple
+	 * devices concurrently if controller supports multiple
+	 * address filters.
+	 *
+	 * This quirk must be set before hci_register_dev is called.
+	 */
+	HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER,
 };
 
 /* HCI device flags */
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index bf5cee48916c..b80a2162a5c3 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -91,6 +91,33 @@ struct msft_ev_le_monitor_device {
 struct msft_monitor_advertisement_handle_data {
 	__u8  msft_handle;
 	__u16 mgmt_handle;
+	__s8 rssi_high;
+	__s8 rssi_low;
+	__u8 rssi_low_interval;
+	__u8 rssi_sampling_period;
+	__u8 cond_type;
+	struct list_head list;
+};
+
+enum monitor_addr_filter_state {
+	AF_STATE_IDLE,
+	AF_STATE_ADDING,
+	AF_STATE_ADDED,
+	AF_STATE_REMOVING,
+};
+
+#define MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR	0x04
+struct msft_monitor_addr_filter_data {
+	__u8     msft_handle;
+	__u8     pattern_handle; /* address filters pertain to */
+	__u16    mgmt_handle;
+	int      state;
+	__s8     rssi_high;
+	__s8     rssi_low;
+	__u8     rssi_low_interval;
+	__u8     rssi_sampling_period;
+	__u8     addr_type;
+	bdaddr_t bdaddr;
 	struct list_head list;
 };
 
@@ -99,9 +126,12 @@ struct msft_data {
 	__u8  evt_prefix_len;
 	__u8  *evt_prefix;
 	struct list_head handle_map;
+	struct list_head address_filters;
 	__u8 resuming;
 	__u8 suspending;
 	__u8 filter_enabled;
+	/* To synchronize add/remove address filter and monitor device event.*/
+	struct mutex filter_lock;
 };
 
 bool msft_monitor_supported(struct hci_dev *hdev)
@@ -180,6 +210,24 @@ static struct msft_monitor_advertisement_handle_data *msft_find_handle_data
 	return NULL;
 }
 
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_find_address_data
+			(struct hci_dev *hdev, u8 addr_type, bdaddr_t *addr,
+			 u8 pattern_handle)
+{
+	struct msft_monitor_addr_filter_data *entry;
+	struct msft_data *msft = hdev->msft_data;
+
+	list_for_each_entry(entry, &msft->address_filters, list) {
+		if (entry->pattern_handle == pattern_handle &&
+		    addr_type == entry->addr_type &&
+		    !bacmp(addr, &entry->bdaddr))
+			return entry;
+	}
+
+	return NULL;
+}
+
 /* This function requires the caller holds hdev->lock */
 static int msft_monitor_device_del(struct hci_dev *hdev, __u16 mgmt_handle,
 				   bdaddr_t *bdaddr, __u8 addr_type,
@@ -240,6 +288,7 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 
 	handle_data->mgmt_handle = monitor->handle;
 	handle_data->msft_handle = rp->handle;
+	handle_data->cond_type   = MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN;
 	INIT_LIST_HEAD(&handle_data->list);
 	list_add(&handle_data->list, &msft->handle_map);
 
@@ -254,6 +303,70 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
 	return status;
 }
 
+/* This function requires the caller holds hci_req_sync_lock */
+static void msft_remove_addr_filters_sync(struct hci_dev *hdev, u8 handle)
+{
+	struct msft_monitor_addr_filter_data *address_filter, *n;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct list_head head;
+	struct sk_buff *skb;
+
+	INIT_LIST_HEAD(&head);
+
+	/* Cancel all corresponding address monitors */
+	mutex_lock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		if (address_filter->pattern_handle != handle)
+			continue;
+
+		list_del(&address_filter->list);
+
+		/* Keep the address filter and let
+		 * msft_add_address_filter_sync() remove and free the address
+		 * filter.
+		 */
+		if (address_filter->state == AF_STATE_ADDING) {
+			address_filter->state = AF_STATE_REMOVING;
+			continue;
+		}
+
+		/* Keep the address filter and let
+		 * msft_cancel_address_filter_sync() remove and free the address
+		 * filter
+		 */
+		if (address_filter->state == AF_STATE_REMOVING)
+			continue;
+
+		list_add_tail(&address_filter->list, &head);
+	}
+
+	mutex_unlock(&msft->filter_lock);
+
+	list_for_each_entry_safe(address_filter, n, &head, list) {
+		list_del(&address_filter->list);
+
+		cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+		cp.handle = address_filter->msft_handle;
+
+		skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+				     HCI_CMD_TIMEOUT);
+		if (IS_ERR_OR_NULL(skb)) {
+			kfree(address_filter);
+			continue;
+		}
+
+		kfree_skb(skb);
+
+		bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+			   &address_filter->bdaddr);
+
+		kfree(address_filter);
+	}
+}
+
 static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						   u16 opcode,
 						   struct adv_monitor *monitor,
@@ -263,6 +376,7 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_data *msft = hdev->msft_data;
 	int status = 0;
+	u8 msft_handle;
 
 	rp = (struct msft_rp_le_cancel_monitor_advertisement *)skb->data;
 	if (skb->len < sizeof(*rp)) {
@@ -293,11 +407,17 @@ static int msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
 						NULL, 0, false);
 		}
 
+		msft_handle = handle_data->msft_handle;
+
 		list_del(&handle_data->list);
 		kfree(handle_data);
-	}
 
-	hci_dev_unlock(hdev);
+		hci_dev_unlock(hdev);
+
+		msft_remove_addr_filters_sync(hdev, msft_handle);
+	} else {
+		hci_dev_unlock(hdev);
+	}
 
 done:
 	return status;
@@ -394,12 +514,14 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 {
 	struct msft_cp_le_monitor_advertisement *cp;
 	struct msft_le_monitor_advertisement_pattern_data *pattern_data;
+	struct msft_monitor_advertisement_handle_data *handle_data;
 	struct msft_le_monitor_advertisement_pattern *pattern;
 	struct adv_pattern *entry;
 	size_t total_size = sizeof(*cp) + sizeof(*pattern_data);
 	ptrdiff_t offset = 0;
 	u8 pattern_count = 0;
 	struct sk_buff *skb;
+	int err;
 
 	if (!msft_monitor_pattern_valid(monitor))
 		return -EINVAL;
@@ -436,16 +558,31 @@ static int msft_add_monitor_sync(struct hci_dev *hdev,
 
 	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, total_size, cp,
 			     HCI_CMD_TIMEOUT);
-	kfree(cp);
 
 	if (IS_ERR_OR_NULL(skb)) {
-		if (!skb)
-			return -EIO;
-		return PTR_ERR(skb);
+		err = PTR_ERR(skb);
+		goto out_free;
 	}
 
-	return msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
-						monitor, skb);
+	err = msft_le_monitor_advertisement_cb(hdev, hdev->msft_opcode,
+					       monitor, skb);
+	if (err)
+		goto out_free;
+
+	handle_data = msft_find_handle_data(hdev, monitor->handle, true);
+	if (!handle_data) {
+		err = -ENODATA;
+		goto out_free;
+	}
+
+	handle_data->rssi_high	= cp->rssi_high;
+	handle_data->rssi_low	= cp->rssi_low;
+	handle_data->rssi_low_interval	  = cp->rssi_low_interval;
+	handle_data->rssi_sampling_period = cp->rssi_sampling_period;
+
+out_free:
+	kfree(cp);
+	return err;
 }
 
 /* This function requires the caller holds hci_req_sync_lock */
@@ -538,6 +675,7 @@ void msft_do_close(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 	struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
+	struct msft_monitor_addr_filter_data *address_filter, *n;
 	struct adv_monitor *monitor;
 
 	if (!msft)
@@ -559,6 +697,14 @@ void msft_do_close(struct hci_dev *hdev)
 		kfree(handle_data);
 	}
 
+	mutex_lock(&msft->filter_lock);
+	list_for_each_entry_safe(address_filter, n, &msft->address_filters,
+				 list) {
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	}
+	mutex_unlock(&msft->filter_lock);
+
 	hci_dev_lock(hdev);
 
 	/* Clear any devices that are being monitored and notify device lost */
@@ -568,6 +714,49 @@ void msft_do_close(struct hci_dev *hdev)
 	hci_dev_unlock(hdev);
 }
 
+static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_cp_le_cancel_monitor_advertisement cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb;
+	int err = 0;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return 0;
+
+	mutex_lock(&msft->filter_lock);
+	list_del(&address_filter->list);
+	mutex_unlock(&msft->filter_lock);
+
+	cp.sub_opcode = MSFT_OP_LE_CANCEL_MONITOR_ADVERTISEMENT;
+	cp.handle = address_filter->msft_handle;
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, sizeof(cp), &cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "MSFT: Failed to cancel address (%pMR) filter",
+			   &address_filter->bdaddr);
+		err = EIO;
+		goto done;
+	}
+	kfree_skb(skb);
+
+	bt_dev_dbg(hdev, "MSFT: Canceled device %pMR address filter",
+		   &address_filter->bdaddr);
+
+done:
+	kfree(address_filter);
+
+	return err;
+}
+
 void msft_register(struct hci_dev *hdev)
 {
 	struct msft_data *msft = NULL;
@@ -581,7 +770,9 @@ void msft_register(struct hci_dev *hdev)
 	}
 
 	INIT_LIST_HEAD(&msft->handle_map);
+	INIT_LIST_HEAD(&msft->address_filters);
 	hdev->msft_data = msft;
+	mutex_init(&msft->filter_lock);
 }
 
 void msft_unregister(struct hci_dev *hdev)
@@ -596,6 +787,7 @@ void msft_unregister(struct hci_dev *hdev)
 	hdev->msft_data = NULL;
 
 	kfree(msft->evt_prefix);
+	mutex_destroy(&msft->filter_lock);
 	kfree(msft);
 }
 
@@ -645,11 +837,149 @@ static void *msft_skb_pull(struct hci_dev *hdev, struct sk_buff *skb,
 	return data;
 }
 
+static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = data;
+	struct msft_rp_le_monitor_advertisement *rp;
+	struct msft_cp_le_monitor_advertisement *cp;
+	struct msft_data *msft = hdev->msft_data;
+	struct sk_buff *skb = NULL;
+	bool remove = false;
+	size_t size;
+
+	if (!msft) {
+		bt_dev_err(hdev, "MSFT: msft data is freed");
+		return -EINVAL;
+	}
+
+	/* The address filter has been removed by hci dev close */
+	if (!test_bit(HCI_UP, &hdev->flags))
+		return -ENODEV;
+
+	/* We are safe to use the address filter from now on.
+	 * msft_monitor_device_evt() wouldn't delete this filter because it's
+	 * not been added by now.
+	 * And all other functions that requiring hci_req_sync_lock wouldn't
+	 * touch this filter before this func completes because it's protected
+	 * by hci_req_sync_lock.
+	 */
+
+	if (address_filter->state == AF_STATE_REMOVING) {
+		mutex_lock(&msft->filter_lock);
+		list_del(&address_filter->list);
+		mutex_unlock(&msft->filter_lock);
+		kfree(address_filter);
+		return 0;
+	}
+
+	size = sizeof(*cp) +
+	       sizeof(address_filter->addr_type) +
+	       sizeof(address_filter->bdaddr);
+	cp = kzalloc(size, GFP_KERNEL);
+	if (!cp) {
+		bt_dev_err(hdev, "MSFT: Alloc cmd param err");
+		remove = true;
+		goto done;
+	}
+	cp->sub_opcode           = MSFT_OP_LE_MONITOR_ADVERTISEMENT;
+	cp->rssi_high		 = address_filter->rssi_high;
+	cp->rssi_low		 = address_filter->rssi_low;
+	cp->rssi_low_interval    = address_filter->rssi_low_interval;
+	cp->rssi_sampling_period = address_filter->rssi_sampling_period;
+	cp->cond_type            = MSFT_MONITOR_ADVERTISEMENT_TYPE_ADDR;
+	cp->data[0]              = address_filter->addr_type;
+	memcpy(&cp->data[1], &address_filter->bdaddr,
+	       sizeof(address_filter->bdaddr));
+
+	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, size, cp,
+			     HCI_CMD_TIMEOUT);
+	if (IS_ERR_OR_NULL(skb)) {
+		bt_dev_err(hdev, "Failed to enable address %pMR filter",
+			   &address_filter->bdaddr);
+		skb = NULL;
+		remove = true;
+		goto done;
+	}
+
+	rp = skb_pull_data(skb, sizeof(*rp));
+	if (!rp || rp->sub_opcode != MSFT_OP_LE_MONITOR_ADVERTISEMENT ||
+	    rp->status)
+		remove = true;
+
+done:
+	mutex_lock(&msft->filter_lock);
+
+	if (remove) {
+		bt_dev_warn(hdev, "MSFT: Remove address (%pMR) filter",
+			    &address_filter->bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+	} else {
+		address_filter->state = AF_STATE_ADDED;
+		address_filter->msft_handle = rp->handle;
+		bt_dev_dbg(hdev, "MSFT: Address %pMR filter enabled",
+			   &address_filter->bdaddr);
+	}
+	mutex_unlock(&msft->filter_lock);
+
+	kfree_skb(skb);
+
+	return 0;
+}
+
+/* This function requires the caller holds msft->filter_lock */
+static struct msft_monitor_addr_filter_data *msft_add_address_filter
+		(struct hci_dev *hdev, u8 addr_type, bdaddr_t *bdaddr,
+		 struct msft_monitor_advertisement_handle_data *handle_data)
+{
+	struct msft_monitor_addr_filter_data *address_filter = NULL;
+	struct msft_data *msft = hdev->msft_data;
+	int err;
+
+	address_filter = kzalloc(sizeof(*address_filter), GFP_KERNEL);
+	if (!address_filter)
+		return NULL;
+
+	address_filter->state             = AF_STATE_ADDING;
+	address_filter->msft_handle       = 0xff;
+	address_filter->pattern_handle    = handle_data->msft_handle;
+	address_filter->mgmt_handle       = handle_data->mgmt_handle;
+	address_filter->rssi_high         = handle_data->rssi_high;
+	address_filter->rssi_low          = handle_data->rssi_low;
+	address_filter->rssi_low_interval = handle_data->rssi_low_interval;
+	address_filter->rssi_sampling_period = handle_data->rssi_sampling_period;
+	address_filter->addr_type            = addr_type;
+	bacpy(&address_filter->bdaddr, bdaddr);
+
+	/* With the above AF_STATE_ADDING, duplicated address filter can be
+	 * avoided when receiving monitor device event (found/lost) frequently
+	 * for the same device.
+	 */
+	list_add_tail(&address_filter->list, &msft->address_filters);
+
+	err = hci_cmd_sync_queue(hdev, msft_add_address_filter_sync,
+				 address_filter, NULL);
+	if (err < 0) {
+		bt_dev_err(hdev, "MSFT: Add address %pMR filter err", bdaddr);
+		list_del(&address_filter->list);
+		kfree(address_filter);
+		return NULL;
+	}
+
+	bt_dev_dbg(hdev, "MSFT: Add device %pMR address filter",
+		   &address_filter->bdaddr);
+
+	return address_filter;
+}
+
 /* This function requires the caller holds hdev->lock */
 static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 {
+	struct msft_monitor_addr_filter_data *n, *address_filter = NULL;
 	struct msft_ev_le_monitor_device *ev;
 	struct msft_monitor_advertisement_handle_data *handle_data;
+	struct msft_data *msft = hdev->msft_data;
+	u16 mgmt_handle = 0xffff;
 	u8 addr_type;
 
 	ev = msft_skb_pull(hdev, skb, MSFT_EV_LE_MONITOR_DEVICE, sizeof(*ev));
@@ -662,9 +992,53 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		   ev->monitor_state, &ev->bdaddr);
 
 	handle_data = msft_find_handle_data(hdev, ev->monitor_handle, false);
-	if (!handle_data)
+
+	if (!test_bit(HCI_QUIRK_USE_MSFT_EXT_ADDRESS_FILTER, &hdev->quirks)) {
+		if (!handle_data)
+			return;
+		mgmt_handle = handle_data->mgmt_handle;
+		goto report_state;
+	}
+
+	if (handle_data) {
+		/* Don't report any device found/lost event from pattern
+		 * monitors. Pattern monitor always has its address filters for
+		 * tracking devices.
+		 */
+
+		address_filter = msft_find_address_data(hdev, ev->addr_type,
+							&ev->bdaddr,
+							handle_data->msft_handle);
+		if (address_filter)
+			return;
+
+		if (ev->monitor_state && handle_data->cond_type ==
+				MSFT_MONITOR_ADVERTISEMENT_TYPE_PATTERN)
+			msft_add_address_filter(hdev, ev->addr_type,
+						&ev->bdaddr, handle_data);
+
 		return;
+	}
 
+	/* This device event is not from pattern monitor.
+	 * Report it if there is a corresponding address_filter for it.
+	 */
+	list_for_each_entry(n, &msft->address_filters, list) {
+		if (n->state == AF_STATE_ADDED &&
+		    n->msft_handle == ev->monitor_handle) {
+			mgmt_handle = n->mgmt_handle;
+			address_filter = n;
+			break;
+		}
+	}
+
+	if (!address_filter) {
+		bt_dev_warn(hdev, "MSFT: Unexpected device event %pMR, %u, %u",
+			    &ev->bdaddr, ev->monitor_handle, ev->monitor_state);
+		return;
+	}
+
+report_state:
 	switch (ev->addr_type) {
 	case ADDR_LE_DEV_PUBLIC:
 		addr_type = BDADDR_LE_PUBLIC;
@@ -681,12 +1055,18 @@ static void msft_monitor_device_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		return;
 	}
 
-	if (ev->monitor_state)
-		msft_device_found(hdev, &ev->bdaddr, addr_type,
-				  handle_data->mgmt_handle);
-	else
-		msft_device_lost(hdev, &ev->bdaddr, addr_type,
-				 handle_data->mgmt_handle);
+	if (ev->monitor_state) {
+		msft_device_found(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	} else {
+		if (address_filter && address_filter->state == AF_STATE_ADDED) {
+			address_filter->state = AF_STATE_REMOVING;
+			hci_cmd_sync_queue(hdev,
+					   msft_cancel_address_filter_sync,
+					   address_filter,
+					   NULL);
+		}
+		msft_device_lost(hdev, &ev->bdaddr, addr_type, mgmt_handle);
+	}
 }
 
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
@@ -724,7 +1104,9 @@ void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb)
 
 	switch (*evt) {
 	case MSFT_EV_LE_MONITOR_DEVICE:
+		mutex_lock(&msft->filter_lock);
 		msft_monitor_device_evt(hdev, skb);
+		mutex_unlock(&msft->filter_lock);
 		break;
 
 	default:
]

gemini-3.7-flash

							input: 20115
							output: 54
							thoughts: 848
						

**Analyzing the Bluetooth HCI Device Lifecycle with MSFT Extension**

Okay, let's break this down methodically. I need to understand this sequence of operations and any potential concurrency issues. Looking at commit `5031ffcc79b81`, I see the `msft_register(hdev)` call is added *after* the `queue_work(..., &hdev->power_on)` call within `hci_register_dev`. That immediately raises a flag.

Diving into `msft_register`, it allocates and initializes the `msft_data` structure and sets up a list head for `handle_map`.  I see `msft_do_close` cleans up the `handle_map` on device close, which involves iterating through a list of `msft_monitor_advertisement_handle_data` structures and resetting the state of associated advertisement monitors. It uses an `idr_find` call.

Now, here's where it gets interesting. I don't see any locking around that `handle_map` or `idr_find` in `5031ffcc79b81`. That's a red flag for concurrent access, especially given the `power_on` workqueue, which *could* be running concurrently.  Wait a minute, was there a lock added *later*? Ah, yes. Commit `9e14606d8f38e` ("Bluetooth: msft: Extended monitor tracking by address filter") introduces `msft->filter_lock`. So the original code *lacked* a lock!

But I need to look at the history before commit `5031ffcc79b81`. When were `idr_init(&hdev->adv_monitors_idr)` and `msft_do_close` introduced?  I need to go further back and figure out the timeline.  I need to check commits `e5e1e7fd470cc` and `1920257316615` and `5031ffcc79b81` and `9e14606d8f38e` to see how everything evolved.  Let's start by doing `git show` on those earlier commits...

map[Commit:e5e1e7fd470cc]

map[Output:commit e5e1e7fd470ccf2eb38ab7fb5a3ab0fc4792fe53
Author: Miao-chen Chou <mcchou@chromium.org>
Date:   Wed Jun 17 16:39:13 2020 +0200

    Bluetooth: Add handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
    
    This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
    command. Since the controller-based monitoring is not yet in place, this
    report only the supported features but not the enabled features.
    
    The following test was performed.
    - Issuing btmgmt advmon-features.
    
    Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 6f88e5d81bd2..4e9d51087674 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -25,6 +25,7 @@
 #ifndef __HCI_CORE_H
 #define __HCI_CORE_H
 
+#include <linux/idr.h>
 #include <linux/leds.h>
 #include <linux/rculist.h>
 
@@ -237,6 +238,24 @@ struct adv_info {
 #define HCI_MAX_ADV_INSTANCES		5
 #define HCI_DEFAULT_ADV_DURATION	2
 
+struct adv_pattern {
+	struct list_head list;
+	__u8 ad_type;
+	__u8 offset;
+	__u8 length;
+	__u8 value[HCI_MAX_AD_LENGTH];
+};
+
+struct adv_monitor {
+	struct list_head patterns;
+	bool		active;
+	__u16		handle;
+};
+
+#define HCI_MIN_ADV_MONITOR_HANDLE		1
+#define HCI_MAX_ADV_MONITOR_NUM_HANDLES	32
+#define HCI_MAX_ADV_MONITOR_NUM_PATTERNS	16
+
 #define HCI_MAX_SHORT_NAME_LENGTH	10
 
 /* Min encryption key size to match with SMP */
@@ -511,6 +530,9 @@ struct hci_dev {
 	__u16			adv_instance_timeout;
 	struct delayed_work	adv_instance_expire;
 
+	struct idr		adv_monitors_idr;
+	unsigned int		adv_monitors_cnt;
+
 	__u8			irk[16];
 	__u32			rpa_timeout;
 	struct delayed_work	rpa_expired;
@@ -1258,6 +1280,8 @@ int hci_add_adv_instance(struct hci_dev *hdev, u8 instance, u32 flags,
 int hci_remove_adv_instance(struct hci_dev *hdev, u8 instance);
 void hci_adv_instances_set_rpa_expired(struct hci_dev *hdev, bool rpa_expired);
 
+void hci_adv_monitors_clear(struct hci_dev *hdev);
+
 void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
 
 void hci_init_sysfs(struct hci_dev *hdev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8e01afb2ee8c..53aec32a5850 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -26,7 +26,6 @@
 /* Bluetooth HCI core. */
 
 #include <linux/export.h>
-#include <linux/idr.h>
 #include <linux/rfkill.h>
 #include <linux/debugfs.h>
 #include <linux/crypto.h>
@@ -2996,6 +2995,12 @@ int hci_add_adv_instance(struct hci_dev *hdev, u8 instance, u32 flags,
 	return 0;
 }
 
+/* This function requires the caller holds hdev->lock */
+void hci_adv_monitors_clear(struct hci_dev *hdev)
+{
+	idr_destroy(&hdev->adv_monitors_idr);
+}
+
 struct bdaddr_list *hci_bdaddr_list_lookup(struct list_head *bdaddr_list,
 					 bdaddr_t *bdaddr, u8 type)
 {
@@ -3646,6 +3651,8 @@ int hci_register_dev(struct hci_dev *hdev)
 
 	queue_work(hdev->req_workqueue, &hdev->power_on);
 
+	idr_init(&hdev->adv_monitors_idr);
+
 	return id;
 
 err_wqueue:
@@ -3716,6 +3723,7 @@ void hci_unregister_dev(struct hci_dev *hdev)
 	hci_smp_irks_clear(hdev);
 	hci_remote_oob_data_clear(hdev);
 	hci_adv_instances_clear(hdev);
+	hci_adv_monitors_clear(hdev);
 	hci_bdaddr_list_clear(&hdev->le_white_list);
 	hci_bdaddr_list_clear(&hdev->le_resolv_list);
 	hci_conn_params_clear_all(hdev);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index e409ff48e8e6..8aec7fbe9a38 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -37,6 +37,7 @@
 #include "smp.h"
 #include "mgmt_util.h"
 #include "mgmt_config.h"
+#include "msft.h"
 
 #define MGMT_VERSION	1
 #define MGMT_REVISION	17
@@ -118,6 +119,7 @@ static const u16 mgmt_commands[] = {
 	MGMT_OP_SET_DEF_RUNTIME_CONFIG,
 	MGMT_OP_GET_DEVICE_FLAGS,
 	MGMT_OP_SET_DEVICE_FLAGS,
+	MGMT_OP_READ_ADV_MONITOR_FEATURES,
 };
 
 static const u16 mgmt_events[] = {
@@ -3973,6 +3975,51 @@ static int set_device_flags(struct sock *sk, struct hci_dev *hdev, void *data,
 				 &cp->addr, sizeof(cp->addr));
 }
 
+static int read_adv_mon_features(struct sock *sk, struct hci_dev *hdev,
+				 void *data, u16 len)
+{
+	struct adv_monitor *monitor = NULL;
+	struct mgmt_rp_read_adv_monitor_features *rp = NULL;
+	int handle;
+	size_t rp_size = 0;
+	__u32 supported = 0;
+	__u16 num_handles = 0;
+	__u16 handles[HCI_MAX_ADV_MONITOR_NUM_HANDLES];
+
+	BT_DBG("request for %s", hdev->name);
+
+	hci_dev_lock(hdev);
+
+	if (msft_get_features(hdev) & MSFT_FEATURE_MASK_LE_ADV_MONITOR)
+		supported |= MGMT_ADV_MONITOR_FEATURE_MASK_OR_PATTERNS;
+
+	idr_for_each_entry(&hdev->adv_monitors_idr, monitor, handle) {
+		handles[num_handles++] = monitor->handle;
+	}
+
+	hci_dev_unlock(hdev);
+
+	rp_size = sizeof(*rp) + (num_handles * sizeof(u16));
+	rp = kmalloc(rp_size, GFP_KERNEL);
+	if (!rp)
+		return -ENOMEM;
+
+	/* Once controller-based monitoring is in place, the enabled_features
+	 * should reflect the use.
+	 */
+	rp->supported_features = cpu_to_le32(supported);
+	rp->enabled_features = 0;
+	rp->max_num_handles = cpu_to_le16(HCI_MAX_ADV_MONITOR_NUM_HANDLES);
+	rp->max_num_patterns = HCI_MAX_ADV_MONITOR_NUM_PATTERNS;
+	rp->num_handles = cpu_to_le16(num_handles);
+	if (num_handles)
+		memcpy(&rp->handles, &handles, (num_handles * sizeof(u16)));
+
+	return mgmt_cmd_complete(sk, hdev->id,
+				 MGMT_OP_READ_ADV_MONITOR_FEATURES,
+				 MGMT_STATUS_SUCCESS, rp, rp_size);
+}
+
 static void read_local_oob_data_complete(struct hci_dev *hdev, u8 status,
 				         u16 opcode, struct sk_buff *skb)
 {
@@ -7441,6 +7488,7 @@ static const struct hci_mgmt_handler mgmt_handlers[] = {
 						HCI_MGMT_VAR_LEN },
 	{ get_device_flags,        MGMT_GET_DEVICE_FLAGS_SIZE },
 	{ set_device_flags,        MGMT_SET_DEVICE_FLAGS_SIZE },
+	{ read_adv_mon_features,   MGMT_READ_ADV_MONITOR_FEATURES_SIZE },
 };
 
 void mgmt_index_added(struct hci_dev *hdev)
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d6c4e6b5ae77..8579bfeb2836 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -139,3 +139,10 @@ void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb)
 
 	bt_dev_dbg(hdev, "MSFT vendor event %u", event);
 }
+
+__u64 msft_get_features(struct hci_dev *hdev)
+{
+	struct msft_data *msft = hdev->msft_data;
+
+	return  msft ? msft->features : 0;
+}
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 5aa9130e1f8a..e9c478e890b8 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -3,16 +3,25 @@
  * Copyright (C) 2020 Google Corporation
  */
 
+#define MSFT_FEATURE_MASK_BREDR_RSSI_MONITOR		BIT(0)
+#define MSFT_FEATURE_MASK_LE_CONN_RSSI_MONITOR		BIT(1)
+#define MSFT_FEATURE_MASK_LE_ADV_RSSI_MONITOR		BIT(2)
+#define MSFT_FEATURE_MASK_LE_ADV_MONITOR		BIT(3)
+#define MSFT_FEATURE_MASK_CURVE_VALIDITY		BIT(4)
+#define MSFT_FEATURE_MASK_CONCURRENT_ADV_MONITOR	BIT(5)
+
 #if IS_ENABLED(CONFIG_BT_MSFTEXT)
 
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb);
+__u64 msft_get_features(struct hci_dev *hdev);
 
 #else
 
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, struct sk_buff *skb) {}
+static inline __u64 msft_get_features(struct hci_dev *hdev) { return 0; }
 
 #endif
]

map[Commit:1920257316615]

map[Output:commit 1920257316615676387794cc5fb838183b3bae7f
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Mon Jan 14 22:33:51 2013 +0200

    Bluetooth: Use req_workqueue for hci_request operations
    
    This patch converts work assignment relying on hci_request() from the
    system-global work queue to the per-HCI device specific work queue
    (hdev->req_workqueue) intended for hci_request() related tasks.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index f73907aad79f..545553b82295 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1146,7 +1146,8 @@ static void hci_power_on(struct work_struct *work)
 		return;
 
 	if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
-		schedule_delayed_work(&hdev->power_off, HCI_AUTO_OFF_TIMEOUT);
+		queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
+				   HCI_AUTO_OFF_TIMEOUT);
 
 	if (test_and_clear_bit(HCI_SETUP, &hdev->dev_flags))
 		mgmt_index_added(hdev);
@@ -1830,7 +1831,7 @@ int hci_register_dev(struct hci_dev *hdev)
 	hci_notify(hdev, HCI_DEV_REG);
 	hci_dev_hold(hdev);
 
-	schedule_work(&hdev->power_on);
+	queue_work(hdev->req_workqueue, &hdev->power_on);
 
 	return id;
 
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 37add53ce613..54114ff4090f 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -812,9 +812,9 @@ static int set_powered(struct sock *sk, struct hci_dev *hdev, void *data,
 	}
 
 	if (cp->val)
-		schedule_work(&hdev->power_on);
+		queue_work(hdev->req_workqueue, &hdev->power_on);
 	else
-		schedule_work(&hdev->power_off.work);
+		queue_work(hdev->req_workqueue, &hdev->power_off.work);
 
 	err = 0;
 
]

gemini-3.7-flash

							input: 25547
							output: 29
							thoughts: 1610
						

**Analyzing the Mutex Corruption in `msft_do_close`**

Okay, let's break this down systematically. The crash report points directly to a mutex corruption within `msft_do_close`, specifically when attempting to lock `msft->filter_lock`. The trace tells us the `DEBUG_LOCKS_WARN_ON` is triggered in the `__mutex_lock_common` function. We need to understand the sequence of events leading up to this point.

My initial thought is to examine the code changes around the introduction of this lock.  The commit `9e14606d8f38ea52a38c27692a9c1513c987a5da`, which I know off the top of my head is the commit that added address filters to the MSFT extension, is the likely culprit.

Looking at that commit, I see the following: `filter_lock` is introduced as a `struct mutex`, and initialized in `msft_register` using `mutex_init(&msft->filter_lock)`.  Critically, the sequence of operations within `msft_register` is now: `INIT_LIST_HEAD(&msft->address_filters); hdev->msft_data = msft; mutex_init(&msft->filter_lock);`. The important observation here is that `hdev->msft_data = msft` occurs *before* `mutex_init(&msft->filter_lock)`.

Now, if we consider that `msft_do_close` which is called from `hci_dev_close_sync` and eventually `hci_power_on` attempts to lock `msft->filter_lock` *after* the device data is assigned, and we consider that `hdev->msft_data` is initialized before the mutex. That does not sound right.

Let's quickly check what `msft_do_close` was like *before* this commit.  Reviewing the pre-`9e14606d8f38ea52a38c27692a9c1513c987a5da` version of `msft_do_close`, which I find in commit `5031ffcc79b81`, shows that it *did not* use the `filter_lock` at all.  It just iterated through the `handle_map` list. The important distinction is that `list_for_each_entry_safe` would not require a lock in the pre-`9e14606d8f38ea52a38c27692a9c1513c987a5da` commit.

So, here's what I am seeing: In the commit in question, the mutex is initialized *after* `hdev->msft_data = msft`. That's likely the cause. It is most likely that the data is not valid for `filter_lock` yet in the scenario.

Therefore, the fix is to move the assignment of `hdev->msft_data = msft;` after `mutex_init(&msft->filter_lock)` or to use `msft_register` to properly assign data. The former makes sense, for now.
To make sure nothing else has introduced another problem, I'll quickly look at the git log for relevant files like `net/bluetooth/msft.c` and `net/bluetooth/hci_core.c` around those functions to verify that no recent changes have introduced any new issues. I'll make sure there are no concurrent changes.

map[Count:10 PathPrefix:net/bluetooth/msft.c]

map[Output:384a4b2fef9f Bluetooth: MGMT: Fix adv monitor add failure cleanup
bf4afc53b77a Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar types
6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
936daee9cf08 Bluetooth: Remove hci_request.{c,h}
10f9f426ac6e Bluetooth: msft: fix slab-use-after-free in msft_do_close()
a6e06258f4c3 Bluetooth: msft: Fix memory leak
41c56aa94c64 Bluetooth: msft: __hci_cmd_sync() doesn't return NULL
528b2acf434b Bluetooth: msft: Fix error code in msft_cancel_address_filter_sync()
9e14606d8f38 Bluetooth: msft: Extended monitor tracking by address filter
]

gemini-3.7-flash

							input: 28267
							output: 53
							thoughts: 33
						

Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested:

**Checking Specific Hashes**

Right, so we've been looking at a particular data set, but I need to make sure we're not missing anything obvious. Let's not get tunnel vision. I've got to ensure we haven't overlooked any potentially related entries. I need to make a quick verification of these two hashes: `10f9f426ac6e` and `a6e06258f4c3`. They might be critical in this. They could either be key to some further analysis, or, at least, confirm that they aren't, thus saving me wasted effort further on. It's a quick check that could prevent me from chasing a rabbit down a hole later.

map[Commit:10f9f426ac6e]

map[Output:commit 10f9f426ac6e752c8d87bf4346930ba347aaabac
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Tue Apr 30 12:20:51 2024 -0400

    Bluetooth: msft: fix slab-use-after-free in msft_do_close()
    
    Tying the msft->data lifetime to hdev by freeing it in
    hci_release_dev() to fix the following case:
    
    [use]
    msft_do_close()
      msft = hdev->msft_data;
      if (!msft)                      ...(1) <- passed.
        return;
      mutex_lock(&msft->filter_lock); ...(4) <- used after freed.
    
    [free]
    msft_unregister()
      msft = hdev->msft_data;
      hdev->msft_data = NULL;         ...(2)
      kfree(msft);                    ...(3) <- msft is freed.
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in __mutex_lock_common
    kernel/locking/mutex.c:587 [inline]
    BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
    kernel/locking/mutex.c:752
    Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309
    
    Fixes: bf6a4e30ffbd ("Bluetooth: disable advertisement filters during suspend")
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a7028d38c1f5..bc5086423ab8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2768,8 +2768,6 @@ void hci_unregister_dev(struct hci_dev *hdev)
 
 	hci_unregister_suspend_notifier(hdev);
 
-	msft_unregister(hdev);
-
 	hci_dev_do_close(hdev);
 
 	if (!test_bit(HCI_INIT, &hdev->flags) &&
@@ -2823,6 +2821,7 @@ void hci_release_dev(struct hci_dev *hdev)
 	hci_discovery_filter_clear(hdev);
 	hci_blocked_keys_clear(hdev);
 	hci_codec_list_clear(&hdev->local_codecs);
+	msft_release(hdev);
 	hci_dev_unlock(hdev);
 
 	ida_destroy(&hdev->unset_handle_ida);
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 9612c5d1b13f..d039683d3bdd 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -769,7 +769,7 @@ void msft_register(struct hci_dev *hdev)
 	mutex_init(&msft->filter_lock);
 }
 
-void msft_unregister(struct hci_dev *hdev)
+void msft_release(struct hci_dev *hdev)
 {
 	struct msft_data *msft = hdev->msft_data;
 
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 2a63205b377b..fe538e9c91c0 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -14,7 +14,7 @@
 
 bool msft_monitor_supported(struct hci_dev *hdev);
 void msft_register(struct hci_dev *hdev);
-void msft_unregister(struct hci_dev *hdev);
+void msft_release(struct hci_dev *hdev);
 void msft_do_open(struct hci_dev *hdev);
 void msft_do_close(struct hci_dev *hdev);
 void msft_vendor_evt(struct hci_dev *hdev, void *data, struct sk_buff *skb);
@@ -35,7 +35,7 @@ static inline bool msft_monitor_supported(struct hci_dev *hdev)
 }
 
 static inline void msft_register(struct hci_dev *hdev) {}
-static inline void msft_unregister(struct hci_dev *hdev) {}
+static inline void msft_release(struct hci_dev *hdev) {}
 static inline void msft_do_open(struct hci_dev *hdev) {}
 static inline void msft_do_close(struct hci_dev *hdev) {}
 static inline void msft_vendor_evt(struct hci_dev *hdev, void *data,
]

map[Commit:a6e06258f4c3]

map[Output:commit a6e06258f4c31eba0fcd503e19828b5f8fe7b08b
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Feb 28 10:56:49 2024 -0500

    Bluetooth: msft: Fix memory leak
    
    Fix leaking buffer allocated to send MSFT_OP_LE_MONITOR_ADVERTISEMENT.
    
    Fixes: 9e14606d8f38 ("Bluetooth: msft: Extended monitor tracking by address filter")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 630e3023273b..9612c5d1b13f 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -875,6 +875,7 @@ static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
 		remove = true;
 		goto done;
 	}
+
 	cp->sub_opcode           = MSFT_OP_LE_MONITOR_ADVERTISEMENT;
 	cp->rssi_high		 = address_filter->rssi_high;
 	cp->rssi_low		 = address_filter->rssi_low;
@@ -887,6 +888,8 @@ static int msft_add_address_filter_sync(struct hci_dev *hdev, void *data)
 
 	skb = __hci_cmd_sync(hdev, hdev->msft_opcode, size, cp,
 			     HCI_CMD_TIMEOUT);
+	kfree(cp);
+
 	if (IS_ERR(skb)) {
 		bt_dev_err(hdev, "Failed to enable address %pMR filter",
 			   &address_filter->bdaddr);
]

gemini-3.7-flash

							input: 30404
							output: 36
							thoughts: 2098
						

**Bug Analysis: Uninitialized Mutex in Bluetooth MSFT Extension**

Okay, let's break this down. The core issue appears to be an uninitialized mutex, triggering a lock warning. My immediate thought is to trace the introduction of this mutex and its usage in relation to the device's initialization and closure routines.

First, I reviewed the crash log and the explanation points to a race condition during HCI device registration, specifically with the MSFT extension data initialization and the `power_on` workqueue. The warning `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` immediately screams "uninitialized mutex" to me.

My focus goes to determining which commit introduced this mutex and whether there was a change in the initialization order that is causing the lock to be uninitialized.

Before the introduction of the mutex, the MSFT extension's `msft_register` function simply allocated memory for the `msft_data` structure and initialized a list head (`handle_map`). The `msft_do_close` function iterates over the `handle_map` without any locking.

Now, after commit `9e14606d8f38e`, a mutex `filter_lock` was added to `msft_data`. Looking closely, `msft_register` *now* initializes this mutex. However, I can already see the problem! The key lies in the order of operations within `msft_register`: `hdev->msft_data = msft;` is performed *before* `mutex_init(&msft->filter_lock);`.

This is a red flag. If `msft_do_close` is called *before* `mutex_init` is called, we'll hit the uninitialized mutex issue. It's likely that, even if `mutex_init` is run before `hdev->msft_data = msft;`, if `queue_work` is called, `msft_do_close` could still be run before `msft_register` is finished.  The timing of the `power_on` workqueue relative to the `msft_register` call is critical here.

I then went back and verified this wasn't an issue in an earlier commit by looking at commit `5031ffcc79b81`. It seemed safe because `hdev->msft_data` was assigned after the allocation and `INIT_LIST_HEAD` but before the actual call to `idr_init`. There are no mutexes at all!

The issue, therefore, seems to be a direct consequence of commit `9e14606d8f38e`, specifically the introduction of the `filter_lock` mutex and, critically, the order in which the mutex is initialized relative to the assignment of `hdev->msft_data`.

I confirmed the relevant commit is indeed `9e14606d8f38ea52a38c27692a9c1513c987a5da` by checking the subject, author, and date.
I would also read `net/bluetooth/msft.c` around line 693 to check if the code around the lock makes sense.

map[File:net/bluetooth/msft.c FirstLine:670 LineCount:50]

map[Contents: 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
 700:	
 701:		hci_dev_lock(hdev);
 702:	
 703:		/* Clear any devices that are being monitored and notify device lost */
 704:		hdev->advmon_pend_notify = false;
 705:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 706:	
 707:		hci_dev_unlock(hdev);
 708:	}
 709:	
 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
 715:		struct sk_buff *skb;
 716:		int err = 0;
 717:	
 718:		if (!msft) {
 719:			bt_dev_err(hdev, "MSFT: msft data is freed");
]

gemini-3.7-flash

							input: 34048
							output: 55
							thoughts: 348
						

**Analyzing the Bluesmoke Driver and Identifying a Potential Regression**

Okay, so line 693 in `net/bluetooth/msft.c` is where the crash is happening, specifically at `mutex_lock(&msft->filter_lock);`. The stack trace, `msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693`, confirms this pinpoint accuracy.

Looking at the code around `msft_register`, it's clear we initialize `msft->filter_lock` with `mutex_init`. So, the core data structure is set up as expected.

`msft_register` looks perfectly fine.

Based on the evidence, the line and trace point directly to commit `9e14606d8f38ea52a38c27692a9c1513c987a5da` as the culprit. I'm going to set `9e14606d8f38ea52a38c27692a9c1513c987a5da` as the result.

map[FixesHash:9e14606d8f38ea52a38c27692a9c1513c987a5da]

map[FixesHash:9e14606d8f38ea52a38c27692a9c1513c987a5da]

map[Fixes:map[AuthorEmail:hildawu@realtek.com AuthorName:Hilda Wu Hash:9e14606d8f38ea52a38c27692a9c1513c987a5da Title:Bluetooth: msft: Extended monitor tracking by address filter]]

map[Recipients:[map[Email:linux-bluetooth@vger.kernel.org Name: To:true] map[Email:linux-kernel@vger.kernel.org Name: To:false] map[Email:luiz.dentz@gmail.com Name:Luiz Augusto von Dentz To:true] map[Email:marcel@holtmann.org Name:Marcel Holtmann To:true] map[Email:hildawu@realtek.com Name:Hilda Wu To:true]]]

map[RecentCommits:Bluetooth: MGMT: Fix adv monitor add failure cleanup
Bluetooth: Add SPDX id lines to some source files
Bluetooth: hci_core: Fix UAF in hci_unregister_dev()
Bluetooth: hci_core: Rework hci_dev_do_reset() to use hci_sync functions
Bluetooth: hci_core: Rate limit the logging of invalid ISO handle
Bluetooth: hci_sync: annotate data-races around hdev->req_status
Convert 'alloc_flex' family to use the new default GFP_KERNEL argument
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
Bluetooth: hci_core: Export hci_discovery_active
Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP
Bluetooth: hci_core: Print information of hcon on hci_low_sent
Bluetooth: hci_core: Print number of packets in conn->data_q
Bluetooth: hci_core: Detect if an ISO link has stalled
Bluetooth: HCI: Fix using LE/ACL buffers for ISO packets
Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections
Bluetooth: hci_core: Eliminate an unnecessary goto label in hci_find_irk_by_addr()
Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
]

core

You are an experienced Linux kernel developer tasked with writing a commit description for
a kernel bug fixing commit. The description should start with a one-line summary,
and then include description of the bug being fixed, and how it's fixed by the provided patch.
The one-line summary should describe the change being made, rather than mention the tool that
detected the bug.

The description must not contain lines starting with '#' because they will dropped by git as comments.
The description must not contain lines starting with '--' or '---' (including inline code diffs)
because they may confuse git/patch utilities.

Your final reply should contain only the text of the commit description.


The one-line summary must be not longer than 72 characters.

IMPORTANT: Do not wrap lines manually (e.g., at 80 characters); we will reformat the text
automatically, so keep paragraphs as single lines without newlines.

Generally try to phrase the description without mentioning syzkaller
(avoid phrases like "the bug was triggered by syzkaller" or "the bug was triggered by fuzzer", etc).
How the bug was triggered is generally an irrelevant detail.
Any bug triggered by a fuzzer can also be triggered by a malicious user, or a buggy program.

If the crash is reported by a sanitizer (e.g., KASAN, KMSAN, lockdep), include the relevant
parts of the sanitizer output to illustrate the problem. Exclude less relevant sections,
as the stack trace can be very long. Describe the execution path that leads to the manifestation
of the kernel bug.


If the patch removes the WARN_ON macro, refer to the fact that WARN_ON
must not be used for conditions that can legitimately happen, and that pr_err
should be used instead if necessary.

Don't assume that panic_on_warn is set, and that WARNINGs are fatal.
While panic_on_warn may be set when the bug was reproduced, it's generally not set on production systems.


Prefer calling several tools at the same time to save round-trips.

The crash that corresponds to the bug is:

------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline], CPU#1: kworker/u11:2/5607
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821, CPU#1: kworker/u11:2/5607
Modules linked in:
CPU: 1 UID: 0 PID: 5607 Comm: kworker/u11:2 Not tainted syzkaller #1 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: hci3 hci_power_on
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:625 [inline]
RIP: 0010:__mutex_lock+0x12df/0x1550 kernel/locking/mutex.c:821
Code: 29 61 90 48 c1 e8 03 0f b6 04 18 84 c0 0f 85 47 02 00 00 83 3d c5 f7 aa 04 00 75 13 48 8d 3d a8 43 ae 04 48 c7 c6 c0 c5 cd 8b <67> 48 0f b9 3a 90 e9 75 ee ff ff 90 0f 0b 90 e9 48 f2 ff ff 90 0f
RSP: 0018:ffffc90004547720 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffff888115658000
RDX: 0000000000000000 RSI: ffffffff8bcdc5c0 RDI: ffffffff90647540
RBP: ffffc900045478b0 R08: ffffffff90612953 R09: 1ffffffff20c252a
R10: dffffc0000000000 R11: fffffbfff20c252b R12: ffff88818c5d3a40
R13: 0000000000000000 R14: 1ffff920008a8ef8 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8882e86de000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd706dfc30 CR3: 0000000118cf8000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
----------------
Code disassembly (best guess):
   0:	29 61 90             	sub    %esp,-0x70(%rcx)
   3:	48 c1 e8 03          	shr    $0x3,%rax
   7:	0f b6 04 18          	movzbl (%rax,%rbx,1),%eax
   b:	84 c0                	test   %al,%al
   d:	0f 85 47 02 00 00    	jne    0x25a
  13:	83 3d c5 f7 aa 04 00 	cmpl   $0x0,0x4aaf7c5(%rip)        # 0x4aaf7df
  1a:	75 13                	jne    0x2f
  1c:	48 8d 3d a8 43 ae 04 	lea    0x4ae43a8(%rip),%rdi        # 0x4ae43cb
  23:	48 c7 c6 c0 c5 cd 8b 	mov    $0xffffffff8bcdc5c0,%rsi
* 2a:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2f:	90                   	nop
  30:	e9 75 ee ff ff       	jmp    0xffffeeaa
  35:	90                   	nop
  36:	0f 0b                	ud2
  38:	90                   	nop
  39:	e9 48 f2 ff ff       	jmp    0xfffff286
  3e:	90                   	nop
  3f:	0f                   	.byte 0xf




The explanation of the root cause of the bug is:

This crash is caused by a race condition during the registration of a new Bluetooth HCI device, specifically between the initialization of the Microsoft (MSFT) extension data and the execution of the device's `power_on` workqueue.

### Root Cause Analysis

1. **Triggering the Bug**: The syzkaller reproducer creates a Virtual HCI device (`/dev/vhci`) and writes a vendor packet with opcode `0x80` (`\xff\x80`). In `__vhci_create_device()`, this specific opcode sets the `HCI_QUIRK_RAW_DEVICE` quirk on the new HCI device and then calls `hci_register_dev(hdev)`.
2. **Device Registration**: Inside `hci_register_dev()` (`net/bluetooth/hci_core.c`), because the `HCI_QUIRK_RAW_DEVICE` quirk is set, the device is marked with the `HCI_UNCONFIGURED` flag.
3. **The Race Condition**: Towards the end of `hci_register_dev()`, the code queues the `power_on` work **before** fully initializing the device's MSFT extension and IDR:
   ```c
   	queue_work(hdev->req_workqueue, &hdev->power_on); // <--- Work is queued here

   	idr_init(&hdev->adv_monitors_idr);
   	msft_register(hdev);                              // <--- MSFT initialized here
   ```
4. **Concurrent Execution**: As soon as `queue_work()` is called, the `power_on` work can start executing concurrently on another CPU, invoking `hci_power_on()`. 
5. **Closing the Unconfigured Device**: Inside `hci_power_on()`, it checks if the device is unconfigured. Since `HCI_UNCONFIGURED` is set, it immediately bails out and calls `hci_dev_do_close(hdev)`, which in turn calls `hci_dev_close_sync(hdev)` and finally `msft_do_close(hdev)`.
6. **Uninitialized Mutex Access**: Concurrently, the original thread is executing `msft_register(hdev)` (`net/bluetooth/msft.c`):
   ```c
   	msft = kzalloc_obj(*msft);
   	// ...
   	INIT_LIST_HEAD(&msft->handle_map);
   	INIT_LIST_HEAD(&msft->address_filters);
   	hdev->msft_data = msft;               // <--- Pointer is exposed
   	mutex_init(&msft->filter_lock);       // <--- Mutex initialized AFTER exposure
   ```
   If `msft_do_close()` reads `hdev->msft_data` after it has been assigned but *before* `mutex_init()` is called, it will see a non-NULL pointer and attempt to lock the uninitialized (zeroed) mutex:
   ```c
   	mutex_lock(&msft->filter_lock);
   ```
   Locking an uninitialized mutex triggers the `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` warning seen in the crash log.

### Proposed Fix

To fix this issue, two changes should be made to ensure proper initialization ordering:

**1. Fix the initialization order in `hci_register_dev`:**
The device must be fully initialized before any work that might use it is scheduled. Move `idr_init()` and `msft_register()` to be called *before* `queue_work()`.

```c
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2631,10 +2631,10 @@ int hci_register_dev(struct hci_dev *hdev)
 		if (error)
 			BT_WARN("register suspend notifier failed error:%d\n", error);
 
-		queue_work(hdev->req_workqueue, &hdev->power_on);
-
 		idr_init(&hdev->adv_monitors_idr);
 		msft_register(hdev);
 
+		queue_work(hdev->req_workqueue, &hdev->power_on);
+
 		return id;
```

**2. Fix the pointer exposure in `msft_register`:**
As a defensive measure, `hdev->msft_data` should only be assigned *after* the structure is fully initialized. This prevents any concurrent readers from observing a partially initialized state.

```c
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,6 +764,6 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
```

The diff of the bug fix is:

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 5ba9fe826..771b73c99 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2629,11 +2629,11 @@ int hci_register_dev(struct hci_dev *hdev)
 	if (error)
 		BT_WARN("register suspend notifier failed error:%d\n", error);
 
-	queue_work(hdev->req_workqueue, &hdev->power_on);
-
 	idr_init(&hdev->adv_monitors_idr);
 	msft_register(hdev);
 
+	queue_work(hdev->req_workqueue, &hdev->power_on);
+
 	return id;
 
 err_wqueue:
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d7badce87..255163033 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -764,8 +764,8 @@ void msft_register(struct hci_dev *hdev)
 
 	INIT_LIST_HEAD(&msft->handle_map);
 	INIT_LIST_HEAD(&msft->address_filters);
-	hdev->msft_data = msft;
 	mutex_init(&msft->filter_lock);
+	hdev->msft_data = msft;
 }
 
 void msft_release(struct hci_dev *hdev)


Additional description of the patch:

### Summary of Changes

1. **Reorder Device Registration and Workqueue Scheduling (`net/bluetooth/hci_core.c`):**
   In `hci_register_dev()`, scheduling `&hdev->power_on` on the request workqueue was previously done *before* initializing the advertisement monitor IDR (`idr_init(&hdev->adv_monitors_idr)`) and Microsoft extension state (`msft_register(hdev)`). For devices marked with quirks like `HCI_QUIRK_RAW_DEVICE` (flagged as `HCI_UNCONFIGURED`), the asynchronously scheduled `hci_power_on` worker immediately triggers `hci_dev_do_close()` and `msft_do_close()`. By moving `queue_work(hdev->req_workqueue, &hdev->power_on)` to after `idr_init()` and `msft_register()`, the device data structures and extensions are guaranteed to be fully initialized before any asynchronous work or cleanup routines can access them.

2. **Publish MSFT Extension State After Complete Initialization (`net/bluetooth/msft.c`):**
   In `msft_register()`, `hdev->msft_data = msft;` was previously assigned before initializing the `filter_lock` mutex (`mutex_init(&msft->filter_lock)`). This exposed a partially initialized `struct msft_data` instance to concurrent teardown and callback paths (such as `msft_do_close()`), resulting in a lock attempt on an uninitialized mutex (`DEBUG_LOCKS_WARN_ON(lock->magic != lock)`). We moved the assignment `hdev->msft_data = msft;` to the very end of `msft_register()` after all list heads and mutexes have been initialized.

Here are summaries of recent commits that touched the same files.
Format the summary line consistently with these, look how prefixes
are specified, letter capitalization, style, etc. 

Bluetooth: MGMT: Fix adv monitor add failure cleanup
Bluetooth: Add SPDX id lines to some source files
Bluetooth: hci_core: Fix UAF in hci_unregister_dev()
Bluetooth: hci_core: Rework hci_dev_do_reset() to use hci_sync functions
Bluetooth: hci_core: Rate limit the logging of invalid ISO handle
Bluetooth: hci_sync: annotate data-races around hdev->req_status
Convert 'alloc_flex' family to use the new default GFP_KERNEL argument
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
Bluetooth: hci_core: Export hci_discovery_active
Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP
Bluetooth: hci_core: Print information of hcon on hci_low_sent
Bluetooth: hci_core: Print number of packets in conn->data_q
Bluetooth: hci_core: Detect if an ISO link has stalled
Bluetooth: HCI: Fix using LE/ACL buffers for ISO packets
Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections
Bluetooth: hci_core: Eliminate an unnecessary goto label in hci_find_irk_by_addr()
Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
Bluetooth: hci_core: Fix use-after-free in vhci_flush()

Bluetooth: hci_core: Fix race condition during device registration

In hci_register_dev(), the power_on work item is queued to
hdev->req_workqueue before initializing hdev->adv_monitors_idr and
registering the MSFT extension via msft_register(). For devices marked with
quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on
the device. When the power_on work item runs concurrently on another CPU,
hci_power_on() detects that the device is unconfigured and immediately
invokes hci_dev_do_close(), which calls msft_do_close().

Concurrently, msft_register() allocates the msft structure and exposes it
to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If
msft_do_close() executes while hdev->msft_data is already assigned but the
mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates
on an uninitialized mutex, triggering a DEBUG_LOCKS warning:

DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common
kernel/locking/mutex.c:625 [inline]
WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550
kernel/locking/mutex.c:821
...
Call Trace:
 <TASK>
 msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693
 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522
 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]
 hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937
 process_one_work kernel/workqueue.c:3322 [inline]
 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Fix this by moving the queue_work() call in hci_register_dev() to after
idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device
structures and extensions are fully initialized before asynchronous tasks
can access them. Additionally, assign hdev->msft_data in msft_register()
only after mutex_init(&msft->filter_lock) has completed.

gemini-3.7-flash

							input: 8164
							output: 23
							thoughts: 978
						

**Crafting the Bluetooth Commit Description**

Okay, the task is to craft a concise and accurate commit description for this Bluetooth subsystem bug fix. I need to adhere strictly to the guidelines: a 72-character or less summary line, avoiding specific keywords like "syzkaller" or "fuzzer," and formatting the description appropriately without line wrapping. The goal is to provide enough information for a reviewer or a future developer to understand the problem and the solution.

First, I examined the crash log. It's a `DEBUG_LOCKS_WARN_ON` triggered by a mutex issue within `msft_do_close`. The call trace leads from `msft_do_close` through `hci_dev_close_sync` and `hci_power_on`, hinting at a synchronization problem during device closure. The key is to convey this specific sequence of events concisely. I'll need to phrase this without getting bogged down in the intricacies of the exact work queue and kthread context. The mutex is the core issue.

Now, I'll review recent commit titles within the Bluetooth subsystem, focusing on `msft` and `hci_core` to establish a proper stylistic consistency. It looks like the most relevant commits are prefixed with `Bluetooth: hci_core:` or `Bluetooth:`. Length is key, so I'll shoot for the former for precision. I'll also ensure that the description avoids any lines that might conflict with git's parsing, such as those beginning with '#' or '--'. I should focus on describing the problem concisely.

Based on this analysis, I'll construct the commit description.

map[Count:5 PathPrefix:net/bluetooth]

map[Output:abd93c85c866 Bluetooth: SCO: give the socket its own sco_conn reference
c0a9dcd2be39 Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync
2c1e4e00613d Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync
abf9753edf3f Bluetooth: hci_sync: hold conn in hci_past_sync() callback
44fc74069d89 Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback
]

gemini-3.7-flash

							input: 9664
							output: 28
							thoughts: 29
						

Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested:

**Investigating Bluetooth Driver Changes**

Alright, time to dig into what's been happening in the Bluetooth subsystem. I need to get a clear picture of recent modifications, specifically within the Microsoft-specific code, so `net/bluetooth/msft.c` is on my radar, and of course, I need to understand any changes that might have impacted the core HCI layer, so `net/bluetooth/hci_core.c` is the other file of interest. Let's start with a deep dive into the Git logs for those two files. I'm hoping to spot any patterns, identify the contributing developers, and understand the motivations behind the updates. Grabbing that `git log` should tell the story... hopefully, the commit messages are descriptive enough! This is going to be good.

map[Count:5 PathPrefix:net/bluetooth/msft.c]

map[Output:384a4b2fef9f Bluetooth: MGMT: Fix adv monitor add failure cleanup
bf4afc53b77a Convert 'alloc_obj' family to use the new default GFP_KERNEL argument
69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar types
6851a0c228fc Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
936daee9cf08 Bluetooth: Remove hci_request.{c,h}
]

gemini-3.7-flash

							input: 10054
							output: 26
							thoughts: 207
						

**Title Selection & Scope Assessment**

Okay, let's nail down this commit title. I've got a few options floating around: "Bluetooth: Fix race condition during HCI device registration" (59 chars), "Bluetooth: hci_core: Fix race during device registration" (56 chars), "Bluetooth: hci_core: Fix race condition in hci_register_dev()" (61 chars), and "Bluetooth: Fix race condition in hci_register_dev()" (52 chars). Hmm, considering the scope, I think the critical elements are *race condition*, *device registration*, and the fact that it's in the *hci_core* area.

Now, let's verify if the patch touches both `net/bluetooth/hci_core.c` and `net/bluetooth/msft.c`. Yes, it does. Okay, that helps narrow it down. Based on that, I'm leaning towards "Bluetooth: hci_core: Fix race condition in hci_register_dev()" or perhaps just "Bluetooth: Fix race condition in hci_register_dev()". Let's run a quick `git log` search using `Bluetooth: Fix ...` and `Bluetooth: hci_core: Fix ...` to see what's been used historically to see if there's a convention that I should follow.

map[Count:10 MessageRegexps:[Bluetooth:.*race]]

map[Output:af24e338bf5d Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero
0f8a5dcc6664 Bluetooth: sco: Fix a race condition in sco_sock_timeout()
1b0d946d6f08 Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled
4847c5bca222 Bluetooth: SCO: Fix data-race on sco_pi fields in sco_connect
9ca7053d6215 Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls
c1bb9336ae6b Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
f958c7805b18 Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths
ca40d481079c Bluetooth: ISO: Fix data-race on dst in iso_sock_connect()
68d39ea5e0ad Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error
0ffac654e95c Bluetooth: hci_h4: Fix race during initialization
]

gemini-3.7-flash

							input: 10872
							output: 25
							thoughts: 16
						

Here's my take on those thoughts, tailored for an expert audience:

**Analyzing Bluetooth Commit Styles for Best Practices**

Alright, let's dive in. I'm thinking I should take a look at the commit messages within the `net/bluetooth` subsystem. I want to see how the established maintainers are handling their commit formatting, granularity, and particularly how they're framing the "why" behind their changes, not just the "what." This isn't just about syntax; I'm looking for patterns in how they structure the messages to convey complex technical rationale concisely. Are they emphasizing problem-solution frameworks? Are they linking to relevant RFCs or bug trackers effectively? What level of detail do they aim for, knowing the audience is presumably other Bluetooth experts and kernel developers? I want to see if I can adopt and improve these best practices for my own contributions and to encourage consistency across the project, including where some improvements can be made, or where I can suggest a novel methodology. This is about building a better, clearer, more maintainable commit history – something that’s crucial for collaboration and the long-term health of any complex codebase, especially one as intricate as the Bluetooth stack.

map[Commit:c1bb9336ae6b]

map[Output:commit c1bb9336ae6b54a5f6a353c4bd4ed9a4307e429b
Author: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Date:   Mon May 18 10:49:49 2026 +0800

    Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
    
    Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer
    Dereference (NPD) conditions were observed in the lifecycle management
    of hci_uart.
    
    The primary issue arises because the workqueues (init_ready and
    write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY
    flag is set during TTY close. If a hangup occurs before setup completes,
    hci_uart_tty_close() skips the teardown of these workqueues and
    proceeds to free the `hu` struct. When the scheduled work executes
    later, it blindly dereferences the freed `hu` struct.
    
    Furthermore, several data races and UAFs were identified in the teardown
    sequence:
    1. Calling hci_uart_flush() from hci_uart_close() without effectively
       disabling write_work causes a race condition where both can concurrently
       double-free hu->tx_skb. This happens because protocol timers can
       concurrently invoke hci_uart_tx_wakeup() and requeue write_work.
    2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF
       when vendor specific protocol close callbacks dereference hu->hdev.
    3. In the initialization error paths, failing to take the proto_lock
       write lock before clearing PROTO_READY leads to races with active
       readers. Additionally, hci_uart_tty_receive() accesses hu->hdev
       outside the read lock, leading to UAFs if the initialization error
       path frees hdev concurrently.
    
    Fix these synchronization and lifecycle issues by:
    1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,
       followed immediately by a cancel_work_sync(&hu->write_work). Clearing
       the flag locks out concurrent protocol timers from successfully invoking
       hci_uart_tx_wakeup(), effectively rendering the cancellation permanent
       and preventing the tx_skb double-free.
    2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip
       hu->proto->flush(). This is perfectly safe in the tty_close path
       because hu->proto->close() executes shortly after, which intrinsically
       purges all protocol SKB queues and tears down the state.
    3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)
       across all close and error paths to prevent vendor-level UAFs.
    4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive()
       inside the proto_lock read-side critical section to safely synchronize
       with device unregistration.
    5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely
       flush the workqueue before hci_uart_flush() is invoked via the HCI core.
    6. Utilizing cancel_work_sync() instead of disable_work_sync() across
       all paths to prevent permanently breaking user-space retry capabilities.
    
    Fixes: 3b799254cf6f ("Bluetooth: hci_uart: Cancel init work before unregistering")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 275ea865bc29..47f4902b40b4 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -194,7 +194,15 @@ void hci_uart_init_work(struct work_struct *work)
 	err = hci_register_dev(hu->hdev);
 	if (err < 0) {
 		BT_ERR("Can't register HCI device");
+
+		percpu_down_write(&hu->proto_lock);
 		clear_bit(HCI_UART_PROTO_READY, &hu->flags);
+		percpu_up_write(&hu->proto_lock);
+
+		/* Safely cancel work after clearing flags */
+		cancel_work_sync(&hu->write_work);
+
+		/* Close protocol before freeing hdev */
 		hu->proto->close(hu);
 		hdev = hu->hdev;
 		hu->hdev = NULL;
@@ -263,8 +271,12 @@ static int hci_uart_open(struct hci_dev *hdev)
 /* Close device */
 static int hci_uart_close(struct hci_dev *hdev)
 {
+	struct hci_uart *hu = hci_get_drvdata(hdev);
+
 	BT_DBG("hdev %p", hdev);
 
+	cancel_work_sync(&hu->write_work);
+
 	hci_uart_flush(hdev);
 	hdev->flush = NULL;
 	return 0;
@@ -531,6 +543,7 @@ static void hci_uart_tty_close(struct tty_struct *tty)
 {
 	struct hci_uart *hu = tty->disc_data;
 	struct hci_dev *hdev;
+	bool proto_ready;
 
 	BT_DBG("tty %p", tty);
 
@@ -540,24 +553,38 @@ static void hci_uart_tty_close(struct tty_struct *tty)
 	if (!hu)
 		return;
 
-	hdev = hu->hdev;
-	if (hdev)
-		hci_uart_close(hdev);
+	/* Wait for init_ready to finish to prevent registration races */
+	cancel_work_sync(&hu->init_ready);
 
-	if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
+	proto_ready = test_bit(HCI_UART_PROTO_READY, &hu->flags);
+	if (proto_ready) {
 		percpu_down_write(&hu->proto_lock);
 		clear_bit(HCI_UART_PROTO_READY, &hu->flags);
 		percpu_up_write(&hu->proto_lock);
+	}
 
-		cancel_work_sync(&hu->init_ready);
-		cancel_work_sync(&hu->write_work);
+	/*
+	 * Unconditionally cancel write_work AFTER clearing PROTO_READY.
+	 * This ensures that concurrent protocol timers cannot requeue
+	 * write_work via hci_uart_tx_wakeup(), permanently preventing
+	 * double-free races and UAFs.
+	 */
+	cancel_work_sync(&hu->write_work);
+
+	hdev = hu->hdev;
+	if (hdev)
+		hci_uart_close(hdev); /* proto->flush is safely skipped */
 
+	if (proto_ready) {
 		if (hdev) {
 			if (test_bit(HCI_UART_REGISTERED, &hu->flags))
 				hci_unregister_dev(hdev);
-			hci_free_dev(hdev);
 		}
+		/* Close protocol before freeing hdev (intrinsically purges queues) */
 		hu->proto->close(hu);
+
+		if (hdev)
+			hci_free_dev(hdev);
 	}
 	clear_bit(HCI_UART_PROTO_SET, &hu->flags);
 
@@ -625,11 +652,12 @@ static void hci_uart_tty_receive(struct tty_struct *tty, const u8 *data,
 	 * tty caller
 	 */
 	hu->proto->recv(hu, data, count);
-	percpu_up_read(&hu->proto_lock);
 
 	if (hu->hdev)
 		hu->hdev->stat.byte_rx += count;
 
+	percpu_up_read(&hu->proto_lock);
+
 	tty_unthrottle(tty);
 }
 
@@ -695,6 +723,10 @@ static int hci_uart_register_dev(struct hci_uart *hu)
 		percpu_down_write(&hu->proto_lock);
 		clear_bit(HCI_UART_PROTO_INIT, &hu->flags);
 		percpu_up_write(&hu->proto_lock);
+		/* Cancel work after clearing flags */
+		cancel_work_sync(&hu->write_work);
+
+		/* Close protocol before freeing hdev */
 		hu->proto->close(hu);
 		hu->hdev = NULL;
 		hci_free_dev(hdev);
]

gemini-3.7-flash

							input: 13453
							output: 38
							thoughts: 811
						

**Analyzing a Bluetooth Race Condition**

Okay, let's break this down. First, the one-line summary. It needs to be under 72 characters and capture the essence of the fix. I've got a few options: "Bluetooth: Fix race condition during HCI device registration" (59 chars), "Bluetooth: hci_core: Fix race condition in hci_register_dev()" (61 chars) or "Bluetooth: hci_core: Fix race during device registration" (56 chars). I'll go with "Bluetooth: hci_core: Fix race condition during device registration" because it's the most descriptive and fits the character limit at 67.

Now, for the description. I need to explain the bug and how the patch resolves it, without any line wrapping and omitting lines starting with '#' or '--' or '---'. It's important to keep the paragraphs as single lines. I have the crash log to help illustrate the problem, and I'll need to use it.

Looking at the crash log, I can see a `DEBUG_LOCKS_WARN_ON` indicating a lock corruption issue, specifically with a mutex. The stack trace points to `msft_do_close`, then `hci_dev_close_sync`, and eventually to `hci_power_on` and `hci_register_dev`. This suggests a race condition is occurring related to device registration during closing or power operations.

To fully grasp the context, I need to understand the code flow, so I'll need to examine `hci_register_dev` in `net/bluetooth/hci_core.c` and `msft_register` in `net/bluetooth/msft.c`. I'll keep the description focused on the bug, the fix, and the code sections involved without mentioning specifics of syzkaller if possible. Based on the crash log and the function names, I understand that the issue relates to a race condition.

map[File:net/bluetooth/hci_core.c FirstLine:2620 LineCount:40]

map[Contents:2620:		 * callback.
2621:		 */
2622:		if (hdev->wakeup)
2623:			hdev->conn_flags |= HCI_CONN_FLAG_REMOTE_WAKEUP;
2624:	
2625:		hci_sock_dev_event(hdev, HCI_DEV_REG);
2626:		hci_dev_hold(hdev);
2627:	
2628:		error = hci_register_suspend_notifier(hdev);
2629:		if (error)
2630:			BT_WARN("register suspend notifier failed error:%d\n", error);
2631:	
2632:		queue_work(hdev->req_workqueue, &hdev->power_on);
2633:	
2634:		idr_init(&hdev->adv_monitors_idr);
2635:		msft_register(hdev);
2636:	
2637:		return id;
2638:	
2639:	err_wqueue:
2640:		debugfs_remove_recursive(hdev->debugfs);
2641:		destroy_workqueue(hdev->workqueue);
2642:		destroy_workqueue(hdev->req_workqueue);
2643:	err:
2644:		ida_free(&hci_index_ida, hdev->id);
2645:	
2646:		return error;
2647:	}
2648:	EXPORT_SYMBOL(hci_register_dev);
2649:	
2650:	/* Unregister HCI device */
2651:	void hci_unregister_dev(struct hci_dev *hdev)
2652:	{
2653:		BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
2654:	
2655:		mutex_lock(&hdev->unregister_lock);
2656:		hci_dev_set_flag(hdev, HCI_UNREGISTER);
2657:		mutex_unlock(&hdev->unregister_lock);
2658:	
2659:		write_lock(&hci_dev_list_lock);
]

gemini-3.7-flash

							input: 15315
							output: 36
							thoughts: 21
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into `msft_register`**

Okay, time to get to the heart of the matter. I need to understand how the Microsoft extensions are being integrated within the Bluetooth stack, so I'm going to jump straight into the code. Let's start by examining the `msft_register` function, and it looks like it's located in the `net/bluetooth/msft.c` file. I'm hoping to quickly grasp its role, understand how it's called, and what its dependencies are. It's likely a critical entry point for handling Microsoft-specific quirks or functionalities, and I need to figure out what it's doing under the hood. Hopefully, the code comments are descriptive enough.

map[File:net/bluetooth/msft.c FirstLine:750 LineCount:35]

map[Contents: 750:		return err;
 751:	}
 752:	
 753:	void msft_register(struct hci_dev *hdev)
 754:	{
 755:		struct msft_data *msft = NULL;
 756:	
 757:		bt_dev_dbg(hdev, "Register MSFT extension");
 758:	
 759:		msft = kzalloc_obj(*msft);
 760:		if (!msft) {
 761:			bt_dev_err(hdev, "Failed to register MSFT extension");
 762:			return;
 763:		}
 764:	
 765:		INIT_LIST_HEAD(&msft->handle_map);
 766:		INIT_LIST_HEAD(&msft->address_filters);
 767:		hdev->msft_data = msft;
 768:		mutex_init(&msft->filter_lock);
 769:	}
 770:	
 771:	void msft_release(struct hci_dev *hdev)
 772:	{
 773:		struct msft_data *msft = hdev->msft_data;
 774:	
 775:		if (!msft)
 776:			return;
 777:	
 778:		bt_dev_dbg(hdev, "Unregister MSFT extension");
 779:	
 780:		hdev->msft_data = NULL;
 781:	
 782:		kfree(msft->evt_prefix);
 783:		mutex_destroy(&msft->filter_lock);
 784:		kfree(msft);
]

gemini-3.7-flash

							input: 16025
							output: 37
							thoughts: 38
						

Okay, let's dive into this. Here's my take on those initial thoughts:

**Analyzing the Bluetooth HCI Power-On Sequence**

Alright, my immediate thought is to understand the flow of events during `hci_power_on`. That's where everything usually kicks off. To get a handle on this, I'm going to jump straight into the kernel code, specifically into `net/bluetooth/hci_core.c`. This is where I'd expect the core HCI functions to reside and where I should find the `hci_power_on` function in the Bluetooth stack. I'm keen to trace the exact steps taken to initialize the Bluetooth controller – from hardware bring-up to the point where the device is ready to receive commands. I need to understand what's happening at this critical starting point.

map[File:net/bluetooth/hci_core.c FirstLine:930 LineCount:25]

map[Contents: 930:		 * valid, it is important to turn the device back off.
 931:		 */
 932:		if (hci_dev_test_flag(hdev, HCI_RFKILLED) ||
 933:		    hci_dev_test_flag(hdev, HCI_UNCONFIGURED) ||
 934:		    (!bacmp(&hdev->bdaddr, BDADDR_ANY) &&
 935:		     !bacmp(&hdev->static_addr, BDADDR_ANY))) {
 936:			hci_dev_clear_flag(hdev, HCI_AUTO_OFF);
 937:			hci_dev_do_close(hdev);
 938:		} else if (hci_dev_test_flag(hdev, HCI_AUTO_OFF)) {
 939:			queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
 940:					   HCI_AUTO_OFF_TIMEOUT);
 941:		}
 942:	
 943:		if (hci_dev_test_and_clear_flag(hdev, HCI_SETUP)) {
 944:			/* For unconfigured devices, set the HCI_RAW flag
 945:			 * so that userspace can easily identify them.
 946:			 */
 947:			if (hci_dev_test_flag(hdev, HCI_UNCONFIGURED))
 948:				set_bit(HCI_RAW, &hdev->flags);
 949:	
 950:			/* For fully configured devices, this will send
 951:			 * the Index Added event. For unconfigured devices,
 952:			 * it will send Unconfigued Index Added event.
 953:			 *
 954:			 * Devices with HCI_QUIRK_RAW_DEVICE are ignored
]

gemini-3.7-flash

							input: 16757
							output: 36
							thoughts: 12
						

Okay, I'm ready to dive into that. Let's see what this `msft_do_close` function is all about.

**Analyzing `msft_do_close`**

Alright, my first thought is to understand the context. Is this a financial model, a trading algorithm, a system shutdown routine? The name suggests it's related to Microsoft and a "close" action, likely a position or a transaction. My immediate instinct is to look for the input parameters; what data is this function receiving? Is it a stock ticker, the current market price, a quantity to close? Knowing the inputs will define the scope and purpose immediately.

Next, I need to look for conditional logic; what criteria are used to trigger the close? Is it based on a pre-defined stop-loss, a profit target, a time limit, or perhaps an external event? The meat of this function will be in those conditionals. I'm especially interested in how it handles edge cases and errors. What happens if the order fails to fill? Does it implement any retry mechanisms or does it raise an alert? Does it consider slippage and adjust accordingly?

I also need to see if it utilizes any API calls or interacts with any external services. Does it communicate with a broker or an exchange? How does it handle authentication and authorization? Securely handling these interactions is paramount. I'll need to scrutinize those API calls for best practices and any potential vulnerabilities.

Finally, the function's output is critical. Does it simply log the closing, send a confirmation message, or return some kind of status code? The output will guide the workflow and give me a clear picture of how it's integrated with the larger process. I'll be looking for robust error handling and clear reporting on execution. Ultimately, I need to know how reliable this close action is and what guarantees are in place. Now, let's see the code.

map[File:net/bluetooth/msft.c FirstLine:690 LineCount:25]

map[Contents: 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
 695:					 list) {
 696:			list_del(&address_filter->list);
 697:			kfree(address_filter);
 698:		}
 699:		mutex_unlock(&msft->filter_lock);
 700:	
 701:		hci_dev_lock(hdev);
 702:	
 703:		/* Clear any devices that are being monitored and notify device lost */
 704:		hdev->advmon_pend_notify = false;
 705:		msft_monitor_device_del(hdev, 0, NULL, 0, true);
 706:	
 707:		hci_dev_unlock(hdev);
 708:	}
 709:	
 710:	static int msft_cancel_address_filter_sync(struct hci_dev *hdev, void *data)
 711:	{
 712:		struct msft_monitor_addr_filter_data *address_filter = data;
 713:		struct msft_cp_le_cancel_monitor_advertisement cp;
 714:		struct msft_data *msft = hdev->msft_data;
]

gemini-3.7-flash

							input: 17611
							output: 36
							thoughts: 18
						

Here's my analysis of the `msft_do_close` function, broken down as though it's my own thought process:

**Diving into `msft_do_close`**

Okay, so I need to understand what this `msft_do_close` function is doing. The first thing I always do is look at the beginning. What are the initial checks? What are the immediate conditions it's concerned with? This is crucial for establishing the preconditions and, potentially, identifying any guard clauses or early exits. I'm focusing on those first lines; they set the tone and often dictate the subsequent control flow. Knowing those initial checks gives me a solid foundation for interpreting the rest of the function. I need to get a handle on the assumptions being made right off the bat.

map[File:net/bluetooth/msft.c FirstLine:670 LineCount:25]

map[Contents: 670:		struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
 671:		struct msft_monitor_addr_filter_data *address_filter, *n;
 672:		struct adv_monitor *monitor;
 673:	
 674:		if (!msft)
 675:			return;
 676:	
 677:		bt_dev_dbg(hdev, "Cleanup of MSFT extension");
 678:	
 679:		/* The controller will silently remove all monitors on power off.
 680:		 * Therefore, remove handle_data mapping and reset monitor state.
 681:		 */
 682:		list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
 683:			monitor = idr_find(&hdev->adv_monitors_idr,
 684:					   handle_data->mgmt_handle);
 685:	
 686:			if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
 687:				monitor->state = ADV_MONITOR_STATE_REGISTERED;
 688:	
 689:			list_del(&handle_data->list);
 690:			kfree(handle_data);
 691:		}
 692:	
 693:		mutex_lock(&msft->filter_lock);
 694:		list_for_each_entry_safe(address_filter, n, &msft->address_filters,
]

gemini-3.7-flash

							input: 18256
							output: 24
							thoughts: 809
						

**Analyzing and Fixing a Race Condition in HCI Device Registration**

Okay, here's how I see this. It looks like we've got a classic race condition issue happening during the Bluetooth HCI device registration process. My initial analysis shows that the `hci_register_dev()` function is the culprit. Specifically, the asynchronous `hci_power_on()` work, queued immediately after device registration, can trigger cleanup operations (`msft_do_close()`) before all necessary data structures are fully initialized.

Let me break down my thinking:

1.  We register the device, and if quirks are present, like an unconfigured BD address or flags are set, an `HCI_UNCONFIGURED` flag is set.
2.  Crucially, `queue_work()` for `hci_power_on()` is called *before* we initialize `hdev->adv_monitors_idr` and register the MSFT-specific data (`msft_register(hdev)`).
3.  The `kworker` thread kicks off `hci_power_on()`, which, because of the `HCI_UNCONFIGURED` flag (or similar), calls `hci_dev_do_close()`, leading to a potentially concurrent `msft_do_close()`.
4.  Meanwhile, the registration thread *does* initialize the `msft` structure, but it sets `hdev->msft_data = msft` *before* initializing the mutex `msft->filter_lock`.
5.  This is where the problem arises: If `msft_do_close()` runs concurrently, it accesses the uninitialized `msft->filter_lock`, potentially leading to a kernel warning because we're locking an uninitialized mutex! Furthermore, it accesses an uninitialized `hdev->adv_monitors_idr` during the `idr_find()` call.

The fix I'm proposing is straightforward. First, in `hci_register_dev()`, I want to move the `queue_work()` call *after* the `idr_init(&hdev->adv_monitors_idr)` and `msft_register(hdev)` calls. This will guarantee that all the device-specific subsystems and data structures are fully initialized *before* we kick off any asynchronous power-on work that might trigger a cleanup. Second, in `msft_register()`, I'll defer the assignment of `hdev->msft_data = msft` until *after* the mutex `mutex_init(&msft->filter_lock)` is initialized. This will ensure that any concurrent access will only see fully initialized structures. This should eliminate the race, prevent the warning, and stabilize the HCI device registration process. Given the location of the fix, `hci_core` seems to be the right context for the commit prefix.

map[Count:10 MessageRegexps:[Bluetooth:]]

map[Output:abd93c85c866 Bluetooth: SCO: give the socket its own sco_conn reference
cac43d360c92 Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req()
0cc4b5649ae8 Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read()
b186c18c4843 Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()
c0a9dcd2be39 Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync
2c1e4e00613d Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync
abf9753edf3f Bluetooth: hci_sync: hold conn in hci_past_sync() callback
44fc74069d89 Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback
56e78b670356 Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback
2f5d635ad590 Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks
]

gemini-3.7-flash

							input: 20019
							output: 721
							thoughts: 2006
						

**Bluetooth: Fix race condition during HCI device registration**

I've identified a race condition in `hci_register_dev()`. Specifically, the `hdev->power_on` work is queued before initializing `adv_monitors_idr` and calling `msft_register()`. If a device uses quirks like `HCI_QUIRK_RAW_DEVICE`, the `HCI_UNCONFIGURED` flag is set. Then, `hci_power_on()` runs asynchronously and, finding the device unconfigured, calls `hci_dev_do_close()`, which calls `msft_do_close()`. The bug manifests when in `msft_register()`, `hdev->msft_data` is assigned before `msft->filter_lock` is initialized. This can lead `msft_do_close()` to try and lock an uninitialized mutex, resulting in a lockdep/debug_locks warning: `DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: <TASK> msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>`. To fix this, I've moved `queue_work(hdev->req_workqueue, &hdev->power_on)` after `idr_init(&hdev->adv_monitors_idr)` and `msft_register(hdev)` in `hci_register_dev()`, ensuring proper device setup before the asynchronous work runs, and I publish `hdev->msft_data` in `msft_register()` after mutex initialization to prevent partial access.