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 v2] Bluetooth: hci_debugfs: serialize force_bredr_smp writes
Date: Fri,  3 Jul 2026 16:14:31 +0800	[thread overview]
Message-ID: <20260703081431.922054-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 both pass the state check and run the same
enable or disable transition on one hdev. On the disable side, one writer
can clear hdev->smp_bredr_data while the other still observes the old
force flag and later passes NULL into smp_del_chan(). The double
transition can also leave the force flag out of sync 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>
---
v2:
- Reword commit message to avoid checkpatch's 75-character line warning.

 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 b7f682922a16..ff344564c923 100644
--- a/net/bluetooth/hci_debugfs.c
+++ b/net/bluetooth/hci_debugfs.c
@@ -520,7 +520,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-07-03  8:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03  8:14 Cen Zhang [this message]
2026-07-03 10:10 ` [v2] 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=20260703081431.922054-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