Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH] Bluetooth: hci_debugfs: serialize force_bredr_smp writes
@ 2026-06-18 10:21 Cen Zhang
  2026-06-18 13:21 ` bluez.test.bot
  0 siblings, 1 reply; 2+ messages in thread
From: Cen Zhang @ 2026-06-18 10:21 UTC (permalink / raw)
  To: Marcel Holtmann, Luiz Augusto von Dentz
  Cc: linux-bluetooth, baijiaju1990, zzzccc427

force_bredr_smp_write() calls smp_force_bredr() without hci_dev_lock().
That helper checks HCI_FORCE_BREDR_SMP, updates hdev->smp_bredr_data, and
then toggles the force flag.  Two same-value writers can therefore both
pass the -EALREADY gate and run the same enable or disable transition on
one hdev.

The buggy scenario involves two paths, with each column showing the order
within that path:

debugfs writer A:                         debugfs writer B:
  1. parse enable = false                   1. parse enable = false
  2. test HCI_FORCE_BREDR_SMP as set        2. test HCI_FORCE_BREDR_SMP as set
  3. read hdev->smp_bredr_data              3. read hdev->smp_bredr_data
  4. clear hdev->smp_bredr_data             4. clear hdev->smp_bredr_data
  5. call smp_del_chan(chan)                5. call smp_del_chan(chan)
  6. toggle HCI_FORCE_BREDR_SMP             6. toggle HCI_FORCE_BREDR_SMP

If writer B reaches step 3 after writer A has cleared
hdev->smp_bredr_data but before writer A toggles HCI_FORCE_BREDR_SMP,
writer B still passed the old flag check and can pass NULL into
smp_del_chan().  The double toggle can also leave the force flag
mismatched with the requested state.

Take hci_dev_lock() around smp_force_bredr() in the debugfs write path so
each request observes and applies one stable BR/EDR SMP transition.

Validation reproduced this kernel report:
KASAN null-ptr-deref in smp_del_chan+0x31/0x90
RIP: 0033:0x7faae680d340
RIP: 0010:smp_del_chan+0x31/0x90 [bluetooth]
Read of size 8
Call trace:
  dump_stack_lvl+0x66/0xa0
  kasan_report+0xe0/0x110
  smp_del_chan+0x31/0x90
  smp_force_bredr+0x69/0xc0
  trace_clock_x86_tsc+0x20/0x20
  srso_alias_return_thunk+0x5/0xfbef5
  lock_acquire+0xd0/0x300
  ksys_write+0xd2/0x170
  full_proxy_write+0x9e/0xd0
  vfs_write+0x1b0/0x810
  find_held_lock+0x2b/0x80
  do_user_addr_fault+0x65a/0x890
  rcu_is_watching+0x20/0x50
  do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)
  entry_SYSCALL_64_after_hwframe+0x77/0x7f

Fixes: 300acfdec916 ("Bluetooth: Introduce force_bredr_smp debugfs option for testing")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
 net/bluetooth/hci_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c
index 99e2e9fc70e8..89cc93f5984e 100644
--- a/net/bluetooth/hci_debugfs.c
+++ b/net/bluetooth/hci_debugfs.c
@@ -524,7 +524,9 @@ static ssize_t force_bredr_smp_write(struct file *file,
 	if (err)
 		return err;
 
+	hci_dev_lock(hdev);
 	err = smp_force_bredr(hdev, enable);
+	hci_dev_unlock(hdev);
 	if (err)
 		return err;
 
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-06-18 13:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-18 10:21 [PATCH] Bluetooth: hci_debugfs: serialize force_bredr_smp writes Cen Zhang
2026-06-18 13:21 ` bluez.test.bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox