Linux bluetooth development
 help / color / mirror / Atom feed
From: Cen Zhang <zzzccc427@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org, baijiaju1990@gmail.com,
	zzzccc427@gmail.com
Subject: [PATCH] Bluetooth: hci_debugfs: serialize force_bredr_smp writes
Date: Thu, 18 Jun 2026 18:21:50 +0800	[thread overview]
Message-ID: <20260618102150.3340673-1-zzzccc427@gmail.com> (raw)

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


             reply	other threads:[~2026-06-18 10:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 10:21 Cen Zhang [this message]
2026-06-18 13:21 ` Bluetooth: hci_debugfs: serialize force_bredr_smp writes bluez.test.bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260618102150.3340673-1-zzzccc427@gmail.com \
    --to=zzzccc427@gmail.com \
    --cc=baijiaju1990@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox