* [Bug 221339] AX200 -19 errors on boot after firmware 20260313-1.1
From: bugzilla-daemon @ 2026-04-14 7:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221339-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221339
--- Comment #7 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
(In reply to Paul Menzel from comment #6)
> @Thorsten, only if you didn’t know, but for the Bluetooth subsystem the
> Bugzilla issues are sent to the list [1],
That for some subsystems nevertheless makes no difference (even if they have B:
pointing to a bugzilla im MAINTAINERS, which BT iirc has not), so email I'd say
mail is the best choice.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221339] AX200 -19 errors on boot after firmware 20260313-1.1
From: bugzilla-daemon @ 2026-04-14 7:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221339-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221339
--- Comment #6 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
@Thorsten, only if you didn’t know, but for the Bluetooth subsystem the
Bugzilla issues are sent to the list [1], so the maintainers should be aware.
(And I added Kiron to the GitLab issue.)
[1]:
https://lore.kernel.org/linux-bluetooth/bug-221339-62941@https.bugzilla.kernel.org%2F/T/#t
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221339] AX200 -19 errors on boot after firmware 20260313-1.1
From: bugzilla-daemon @ 2026-04-14 7:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221339-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221339
The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |regressions@leemhuis.info
--- Comment #5 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
(In reply to pallaswept from comment #4)
> keep it in mind for next time.
It's even more complicated, as this bugzilla for most of the kernel is the
wrong place to report bugs (long story), as most reports here do not even reach
the right developers.
> Yes I have confirmed that it was that file, if I roll back to the previous
> version the issues are resolved.
Can I forward this report by mail? This would expose your email address to the
public
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test
From: bugzilla-daemon @ 2026-04-14 6:45 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221346-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221346
Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pmenzel+bugzilla.kernel.org
| |@molgen.mpg.de
--- Comment #3 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
It’d be great if you could comment, what the problem was making you close this
as invalid.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test
From: bugzilla-daemon @ 2026-04-14 6:07 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221346-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221346
Zhang Zhigang (zhangzhigang1996@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-14 5:03 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <eeytuhqpgdz4do4tgtbmfntub2femtyq7bij7svhodpyjwaylx@j3gmvq2a2zqc>
On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> [Resending as my previous reply got bounced]
>
> On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > > > Hi,
> > > >
> > > > This series is the continuation of the series [1] that added the initial support
> > > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > > connectors. These connectors are used to connect the Wireless Connectivity
> > > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > > interfaces are left for future improvements.
> > >
> > > Thanks for working on this. I started playing with it now that it is in
> > > -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
> > >
> > > A couple questions:
> > >
> > > - Given that this connector actually represents two devices, how do I
> > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > Does wakeup-source even work at this point?
> > >
> >
> > You can't use the DT property since the devices are not described in DT
> > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > wakeup.
I see. I think not being able to specify generic properties for the devices
on the connector is going to be a bit problematic. Another use case I have
requires specifying a bounce buffer / SWIOTLB for the PCIe WiFi card. The
PCIe controller does not have an IOMMU behind it.
> > > - Are there plans to do the SDIO part?
> > >
> >
> > No, not at the moment. Feel free to take it up if you have the hardware and
> > motivation :)
Ack. I think I still need to figure out what the plan is after mmc-pwrseq
is deprecated.
> > > - The matching done in the M.2 connector driver for pwrseq_get() seems a
> > > bit naive. It simply checks if the remote device in the OF graph is
> > > the same as the requesting device.
> > >
> > > I think this would run into issues with USB hubs. If I have a USB hub
> > > and two M.2 connectors, with both connectors connected to the same
> > > hub, pwrseq_get() is going to always return only one of the instances.
> > > This is because the USB hub has one device node with multiple OF graph
> > > ports.
> > >
> >
> > Yeah, this is a known limitation. I'm trying to improve this part now and have
> > the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
> >
> > Once the merge window closes, I'll submit these.
I couldn't tell which commit would help with this.
In my head I think we would need to extend pwrseq_get() to add something
like an index parameter that the provider is free to interpret. The M.2
connector driver could interpret it as the USB port number on the remote
end.
Thanks
ChenYu
^ permalink raw reply
* RE: [v2] Bluetooth: RFCOMM: validate skb length in MCC handlers
From: bluez.test.bot @ 2026-04-14 4:01 UTC (permalink / raw)
To: linux-bluetooth, suunj1331
In-Reply-To: <20260414010741.233892-1-suunj1331@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7392 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1080925
---Test result---
Test Summary:
CheckPatch PASS 0.50 seconds
GitLint FAIL 0.24 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 26.89 seconds
CheckAllWarning PASS 29.76 seconds
CheckSparse PASS 28.82 seconds
BuildKernel32 PASS 23.72 seconds
TestRunnerSetup PASS 547.38 seconds
TestRunner_l2cap-tester PASS 28.62 seconds
TestRunner_iso-tester PASS 40.16 seconds
TestRunner_bnep-tester PASS 6.47 seconds
TestRunner_mgmt-tester FAIL 115.76 seconds
TestRunner_rfcomm-tester PASS 10.05 seconds
TestRunner_sco-tester FAIL 14.78 seconds
TestRunner_ioctl-tester PASS 10.80 seconds
TestRunner_mesh-tester FAIL 12.18 seconds
TestRunner_smp-tester PASS 8.87 seconds
TestRunner_userchan-tester PASS 6.84 seconds
TestRunner_6lowpan-tester FAIL 8.69 seconds
IncrementalBuild FAIL 1.15 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: RFCOMM: validate skb length in MCC handlers
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
22: B1 Line exceeds max length (82>80): " - Add a length check in rfcomm_recv_mcc() before accessing the MCC header (Paul)"
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.112 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gd702855ed9de #1 Not tainted
------------------------------------------------------
kworker/u5:2/117 is trying to acquire lock:
ffff888001946240 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_connect_cfm+0x358/0x8d0
but task is already holding lock:
ffff888002141a20 (&conn->lock){+.+.}-{3:3}, at: sco_connect_cfm+0x22d/0x8d0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&conn->lock){+.+.}-{3:3}:
lock_acquire+0xf7/0x2c0
_raw_spin_lock+0x2a/0x40
sco_sock_connect+0x4d7/0x1280
__sys_connect+0x1a3/0x260
__x64_sys_connect+0x6e/0xb0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
check_prev_add+0xe9/0xc70
__lock_acquire+0x1457/0x1df0
lock_acquire+0xf7/0x2c0
lock_sock_nested+0x36/0xd0
sco_connect_cfm+0x358/0x8d0
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
other info that might help us debug this:
...
BUG: sleeping function called from invalid context at net/core/sock.c:3782
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 117, name: kworker/u5:2
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 117 Comm: kworker/u5:2 Not tainted 7.0.0-rc2-gd702855ed9de #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x60
__might_resched+0x2ea/0x500
lock_sock_nested+0x47/0xd0
? sco_connect_cfm+0x358/0x8d0
sco_connect_cfm+0x358/0x8d0
? hci_debugfs_create_conn+0x190/0x210
? __pfx_sco_connect_cfm+0x10/0x10
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
? __pfx_hci_sync_conn_complete_evt+0x10/0x10
? __pfx_hci_event_packet+0x10/0x10
? mark_held_locks+0x49/0x80
? lockdep_hardirqs_on_prepare+0xd4/0x180
? _raw_spin_unlock_irqrestore+0x2c/0x50
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
? __pfx_process_scheduled_works+0x10/0x10
? lock_acquire+0xf7/0x2c0
? lock_is_held_type+0x9b/0x110
? __pfx_hci_rx_work+0x10/0x10
worker_thread+0x4ff/0xba0
? _raw_spin_unlock_irqrestore+0x2c/0x50
? __pfx_worker_thread+0x10/0x10
kthread+0x368/0x490
? _raw_spin_unlock_irq+0x23/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork+0x498/0x7e0
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x9e4/0xe50
? __switch_to_asm+0x32/0x60
...
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.082 seconds
Mesh - Send cancel - 2 Timed out 1.986 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gd702855ed9de #1 Not tainted
------------------------------------------------------
kworker/0:1/11 is trying to acquire lock:
ffff8880026e4940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x75/0x180
but task is already holding lock:
ffffffff9844d720 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (rtnl_mutex){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
lowpan_register_netdev+0x11/0x30
chan_ready_cb+0x836/0xd00
l2cap_recv_frame+0x6a06/0x8920
l2cap_recv_acldata+0x790/0xdf0
hci_rx_work+0x500/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
-> #3 (&chan->lock#3/1){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
l2cap_chan_connect+0x74e/0x1980
lowpan_control_write+0x523/0x660
full_proxy_write+0x10b/0x190
vfs_write+0x1c0/0xf60
ksys_write+0xf1/0x1d0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #2 (&conn->lock){+.+.}-{4:4}:
...
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: IncrementalBuild - FAIL
Desc: Incremental build with the patches in the series
Output:
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
https://github.com/bluez/bluetooth-next/pull/81
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v2] Bluetooth: RFCOMM: validate skb length in MCC handlers
From: SeungJu Cheon @ 2026-04-14 1:07 UTC (permalink / raw)
To: linux-bluetooth
Cc: marcel, luiz.dentz, pmenzel, kees, kuba, me, skhan,
linux-kernel-mentees, linux-kernel, SeungJu Cheon
The RFCOMM MCC handlers cast skb->data to various protocol structs
without validating skb->len first. A malicious remote device can send
short MCC frames to trigger out-of-bounds reads in these handlers.
Fix this by using skb_pull_data() to safely validate and access the
required data in each handler. Return -EINVAL if the skb does not
contain enough data.
rfcomm_recv_rpn() requires special handling since 1-byte RPN requests
are valid per ETSI TS 07.10. Handle this by first pulling a single byte
for the DLCI field, and only validating the full struct when len > 1.
Also add a length check in rfcomm_recv_mcc() before accessing the MCC
header fields.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: SeungJu Cheon <suunj1331@gmail.com>
---
v2:
- Use skb_pull_data() instead of manual length checks (Luiz)
- Add a length check in rfcomm_recv_mcc() before accessing the MCC header (Paul)
- Allow 1-byte RPN requests in rfcomm_recv_rpn() as per ETSI TS 07.10 (Paul)
---
net/bluetooth/rfcomm/core.c | 66 ++++++++++++++++++++++++++++---------
1 file changed, 50 insertions(+), 16 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 611a9a94151e..a2dfbff816d3 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1431,10 +1431,15 @@ static int rfcomm_apply_pn(struct rfcomm_dlc *d, int cr, struct rfcomm_pn *pn)
static int rfcomm_recv_pn(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_pn *pn = (void *) skb->data;
+ struct rfcomm_pn *pn;
struct rfcomm_dlc *d;
- u8 dlci = pn->dlci;
+ u8 dlci;
+
+ pn = skb_pull_data(skb, sizeof(*pn));
+ if (!pn)
+ return -EINVAL;
+ dlci = pn->dlci;
BT_DBG("session %p state %ld dlci %d", s, s->state, dlci);
if (!dlci)
@@ -1483,8 +1488,8 @@ static int rfcomm_recv_pn(struct rfcomm_session *s, int cr, struct sk_buff *skb)
static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_buff *skb)
{
- struct rfcomm_rpn *rpn = (void *) skb->data;
- u8 dlci = __get_dlci(rpn->dlci);
+ struct rfcomm_rpn *rpn;
+ u8 dlci;
u8 bit_rate = 0;
u8 data_bits = 0;
@@ -1495,15 +1500,16 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
u8 xoff_char = 0;
u16 rpn_mask = RFCOMM_RPN_PM_ALL;
- BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xoffc 0x%x pm 0x%x",
- dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl,
- rpn->xon_char, rpn->xoff_char, rpn->param_mask);
+ if (len == 1) {
+ rpn = skb_pull_data(skb, 1);
+ if (!rpn)
+ return -EINVAL;
- if (!cr)
- return 0;
+ dlci = __get_dlci(rpn->dlci);
+
+ if (!cr)
+ return 0;
- if (len == 1) {
- /* This is a request, return default (according to ETSI TS 07.10) settings */
bit_rate = RFCOMM_RPN_BR_9600;
data_bits = RFCOMM_RPN_DATA_8;
stop_bits = RFCOMM_RPN_STOP_1;
@@ -1514,6 +1520,19 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
goto rpn_out;
}
+ rpn = skb_pull_data(skb, sizeof(*rpn));
+ if (!rpn)
+ return -EINVAL;
+
+ dlci = __get_dlci(rpn->dlci);
+
+ BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xoffc 0x%x pm 0x%x",
+ dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl,
+ rpn->xon_char, rpn->xoff_char, rpn->param_mask);
+
+ if (!cr)
+ return 0;
+
/* Check for sane values, ignore/accept bit_rate, 8 bits, 1 stop bit,
* no parity, no flow control lines, normal XON/XOFF chars */
@@ -1589,9 +1608,14 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
static int rfcomm_recv_rls(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_rls *rls = (void *) skb->data;
- u8 dlci = __get_dlci(rls->dlci);
+ struct rfcomm_rls *rls;
+ u8 dlci;
+
+ rls = skb_pull_data(skb, sizeof(*rls));
+ if (!rls)
+ return -EINVAL;
+ dlci = __get_dlci(rls->dlci);
BT_DBG("dlci %d cr %d status 0x%x", dlci, cr, rls->status);
if (!cr)
@@ -1608,10 +1632,15 @@ static int rfcomm_recv_rls(struct rfcomm_session *s, int cr, struct sk_buff *skb
static int rfcomm_recv_msc(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_msc *msc = (void *) skb->data;
+ struct rfcomm_msc *msc;
struct rfcomm_dlc *d;
- u8 dlci = __get_dlci(msc->dlci);
+ u8 dlci;
+
+ msc = skb_pull_data(skb, sizeof(*msc));
+ if (!msc)
+ return -EINVAL;
+ dlci = __get_dlci(msc->dlci);
BT_DBG("dlci %d cr %d v24 0x%x", dlci, cr, msc->v24_sig);
d = rfcomm_dlc_get(s, dlci);
@@ -1644,9 +1673,14 @@ static int rfcomm_recv_msc(struct rfcomm_session *s, int cr, struct sk_buff *skb
static int rfcomm_recv_mcc(struct rfcomm_session *s, struct sk_buff *skb)
{
- struct rfcomm_mcc *mcc = (void *) skb->data;
+ struct rfcomm_mcc *mcc;
u8 type, cr, len;
+ if (skb->len < sizeof(*mcc))
+ return -EINVAL;
+
+ mcc = (void *) skb->data;
+
cr = __test_cr(mcc->type);
type = __get_mcc_type(mcc->type);
len = __get_mcc_len(mcc->len);
--
2.52.0
^ permalink raw reply related
* RE: [v3] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
From: bluez.test.bot @ 2026-04-13 23:52 UTC (permalink / raw)
To: linux-bluetooth, mikhail.v.gavrilov
In-Reply-To: <20260413230813.21393-1-mikhail.v.gavrilov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8839 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1080906
---Test result---
Test Summary:
CheckPatch FAIL 1.25 seconds
GitLint FAIL 0.21 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.15 seconds
CheckAllWarning PASS 33.68 seconds
CheckSparse PASS 28.46 seconds
BuildKernel32 PASS 25.26 seconds
TestRunnerSetup PASS 575.60 seconds
TestRunner_l2cap-tester PASS 28.18 seconds
TestRunner_iso-tester PASS 36.67 seconds
TestRunner_bnep-tester PASS 6.46 seconds
TestRunner_mgmt-tester FAIL 114.28 seconds
TestRunner_rfcomm-tester PASS 9.52 seconds
TestRunner_sco-tester FAIL 14.08 seconds
TestRunner_ioctl-tester PASS 10.36 seconds
TestRunner_mesh-tester FAIL 12.22 seconds
TestRunner_smp-tester PASS 8.67 seconds
TestRunner_userchan-tester PASS 6.72 seconds
TestRunner_6lowpan-tester FAIL 8.48 seconds
IncrementalBuild FAIL 1.35 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
CHECK: Alignment should match open parenthesis
#229: FILE: net/bluetooth/hci_conn.c:518:
+static void le_conn_update_complete(struct hci_dev *hdev, void *data,
+ int err)
ERROR: code indent should use tabs where possible
#237: FILE: net/bluetooth/hci_conn.c:524:
+^I^I u16 to_multiplier)$
CHECK: Alignment should match open parenthesis
#237: FILE: net/bluetooth/hci_conn.c:524:
+void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
+ u16 to_multiplier)
WARNING: Prefer kmalloc_obj over kmalloc with sizeof
#242: FILE: net/bluetooth/hci_conn.c:528:
+ d = kmalloc(sizeof(*d), GFP_KERNEL);
total: 1 errors, 1 warnings, 2 checks, 156 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
/github/workspace/src/patch/14523623.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (87>80): "[v3] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion"
44: B2 Line has trailing whitespace: " "
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.109 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gea668f64ba2a #1 Not tainted
------------------------------------------------------
kworker/u5:2/117 is trying to acquire lock:
ffff8880021b6240 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_connect_cfm+0x358/0x8d0
but task is already holding lock:
ffff8880025f8220 (&conn->lock){+.+.}-{3:3}, at: sco_connect_cfm+0x22d/0x8d0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&conn->lock){+.+.}-{3:3}:
lock_acquire+0xf7/0x2c0
_raw_spin_lock+0x2a/0x40
sco_sock_connect+0x4d7/0x1280
__sys_connect+0x1a3/0x260
__x64_sys_connect+0x6e/0xb0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
check_prev_add+0xe9/0xc70
__lock_acquire+0x1457/0x1df0
lock_acquire+0xf7/0x2c0
lock_sock_nested+0x36/0xd0
sco_connect_cfm+0x358/0x8d0
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
other info that might help us debug this:
...
BUG: sleeping function called from invalid context at net/core/sock.c:3782
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 117, name: kworker/u5:2
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 117 Comm: kworker/u5:2 Not tainted 7.0.0-rc2-gea668f64ba2a #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x60
__might_resched+0x2ea/0x500
lock_sock_nested+0x47/0xd0
? sco_connect_cfm+0x358/0x8d0
sco_connect_cfm+0x358/0x8d0
? hci_debugfs_create_conn+0x190/0x210
? __pfx_sco_connect_cfm+0x10/0x10
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
? __pfx_hci_sync_conn_complete_evt+0x10/0x10
? __pfx_hci_event_packet+0x10/0x10
? mark_held_locks+0x49/0x80
? lockdep_hardirqs_on_prepare+0xd4/0x180
? _raw_spin_unlock_irqrestore+0x2c/0x50
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
? __pfx_process_scheduled_works+0x10/0x10
? lock_acquire+0xf7/0x2c0
? lock_is_held_type+0x9b/0x110
? __pfx_hci_rx_work+0x10/0x10
worker_thread+0x4ff/0xba0
? _raw_spin_unlock_irqrestore+0x2c/0x50
? __pfx_worker_thread+0x10/0x10
kthread+0x368/0x490
? _raw_spin_unlock_irq+0x23/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork+0x498/0x7e0
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x9e4/0xe50
? __switch_to_asm+0x32/0x60
...
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.640 seconds
Mesh - Send cancel - 2 Timed out 1.996 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gea668f64ba2a #1 Not tainted
------------------------------------------------------
kworker/0:1/11 is trying to acquire lock:
ffff8880026e0940 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x75/0x180
but task is already holding lock:
ffffffff8fa4d720 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (rtnl_mutex){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
lowpan_register_netdev+0x11/0x30
chan_ready_cb+0x836/0xd00
l2cap_recv_frame+0x6a07/0x88a0
l2cap_recv_acldata+0x790/0xdf0
hci_rx_work+0x500/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
-> #3 (&chan->lock#3/1){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
l2cap_chan_connect+0x74e/0x1980
lowpan_control_write+0x523/0x660
full_proxy_write+0x10b/0x190
vfs_write+0x1c0/0xf60
ksys_write+0xf1/0x1d0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #2 (&conn->lock){+.+.}-{4:4}:
...
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: IncrementalBuild - FAIL
Desc: Incremental build with the patches in the series
Output:
fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
https://github.com/bluez/bluetooth-next/pull/80
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
From: Mikhail Gavrilov @ 2026-04-13 23:08 UTC (permalink / raw)
To: luiz.dentz, marcel
Cc: pmenzel, linux-bluetooth, linux-kernel, Mikhail Gavrilov
When a BLE peripheral sends an L2CAP Connection Parameter Update Request
the processing path is:
process_pending_rx() [takes conn->lock]
l2cap_le_sig_channel()
l2cap_conn_param_update_req()
hci_le_conn_update() [takes hdev->lock]
Meanwhile other code paths take the locks in the opposite order:
l2cap_chan_connect() [takes hdev->lock]
...
mutex_lock(&conn->lock)
l2cap_conn_ready() [hdev->lock via hci_cb_list_lock]
...
mutex_lock(&conn->lock)
This is a classic AB/BA deadlock which lockdep reports as a circular
locking dependency when connecting a BLE MIDI keyboard (Carry-On FC-49).
Fix this by making hci_le_conn_update() defer the HCI command through
hci_cmd_sync_queue() so it no longer needs to take hdev->lock in the
caller context.
The connection parameter storage (hci_conn_params update) and userspace
notification (mgmt_new_conn_param) are moved into
hci_le_conn_update_complete_evt() where they are handled when the
controller confirms the update, using hci_sent_cmd_data() to retrieve
the originally requested min/max interval values.
Fixes: f044eb0524a0 ("Bluetooth: Store latency and supervision timeout in connection params")
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
Changes in v3 (Luiz Augusto von Dentz):
- Move hci_cmd_sync_queue into hci_le_conn_update itself instead of open-coding
the deferral in l2cap_core.c
- Move conn_params update and mgmt_new_conn_param into
hci_le_conn_update_complete_evt, using hci_sent_cmd_data to retrieve
the originally requested parameters
Changes in v2 (Paul Menzel, Sashiko/Gemini AI review):
- Allocate before sending ACCEPTED response to avoid state mismatch on OOM
- Verify connection handle and address in sync callback against reuse race
- Expand commit message with implementation details
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/hci_conn.c | 66 ++++++++++++++++++++++----------
net/bluetooth/hci_event.c | 33 ++++++++++++++++
net/bluetooth/l2cap_core.c | 12 +-----
4 files changed, 81 insertions(+), 32 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index a7bffb908c1e..aa600fbf9a53 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -2495,7 +2495,7 @@ void mgmt_adv_monitor_device_lost(struct hci_dev *hdev, u16 handle,
bdaddr_t *bdaddr, u8 addr_type);
int hci_abort_conn(struct hci_conn *conn, u8 reason);
-u8 hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
+void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
u16 to_multiplier);
void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __le64 rand,
__u8 ltk[16], __u8 key_size);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 11d3ad8d2551..207221560a02 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -480,40 +480,64 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
return hci_setup_sync_conn(conn, handle);
}
-u8 hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
- u16 to_multiplier)
+struct le_conn_update_data {
+ struct hci_conn *conn;
+ u16 min;
+ u16 max;
+ u16 latency;
+ u16 to_multiplier;
+};
+
+static int le_conn_update_sync(struct hci_dev *hdev, void *data)
{
- struct hci_dev *hdev = conn->hdev;
- struct hci_conn_params *params;
+ struct le_conn_update_data *d = data;
+ struct hci_conn *conn;
struct hci_cp_le_conn_update cp;
hci_dev_lock(hdev);
-
- params = hci_conn_params_lookup(hdev, &conn->dst, conn->dst_type);
- if (params) {
- params->conn_min_interval = min;
- params->conn_max_interval = max;
- params->conn_latency = latency;
- params->supervision_timeout = to_multiplier;
- }
-
+ /* Verify connection is still alive. */
+ conn = hci_conn_valid(hdev, d->conn) ? d->conn : NULL;
hci_dev_unlock(hdev);
+ if (!conn)
+ return -ECANCELED;
memset(&cp, 0, sizeof(cp));
cp.handle = cpu_to_le16(conn->handle);
- cp.conn_interval_min = cpu_to_le16(min);
- cp.conn_interval_max = cpu_to_le16(max);
- cp.conn_latency = cpu_to_le16(latency);
- cp.supervision_timeout = cpu_to_le16(to_multiplier);
+ cp.conn_interval_min = cpu_to_le16(d->min);
+ cp.conn_interval_max = cpu_to_le16(d->max);
+ cp.conn_latency = cpu_to_le16(d->latency);
+ cp.supervision_timeout = cpu_to_le16(d->to_multiplier);
cp.min_ce_len = cpu_to_le16(0x0000);
cp.max_ce_len = cpu_to_le16(0x0000);
- hci_send_cmd(hdev, HCI_OP_LE_CONN_UPDATE, sizeof(cp), &cp);
+ return __hci_cmd_sync_status(hdev, HCI_OP_LE_CONN_UPDATE,
+ sizeof(cp), &cp, HCI_CMD_TIMEOUT);
+}
+
+static void le_conn_update_complete(struct hci_dev *hdev, void *data,
+ int err)
+{
+ kfree(data);
+}
- if (params)
- return 0x01;
+void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max, u16 latency,
+ u16 to_multiplier)
+{
+ struct le_conn_update_data *d;
- return 0x00;
+ d = kmalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return;
+
+ d->conn = conn;
+ d->min = min;
+ d->max = max;
+ d->latency = latency;
+ d->to_multiplier = to_multiplier;
+
+ if (hci_cmd_sync_queue(conn->hdev, le_conn_update_sync, d,
+ le_conn_update_complete) < 0)
+ kfree(d);
}
void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __le64 rand,
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 3ebc5e6d45d9..9df8fc762a84 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -6065,6 +6065,8 @@ static void hci_le_conn_update_complete_evt(struct hci_dev *hdev, void *data,
struct sk_buff *skb)
{
struct hci_ev_le_conn_update_complete *ev = data;
+ struct hci_cp_le_conn_update *sent;
+ struct hci_conn_params *params;
struct hci_conn *conn;
bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
@@ -6079,6 +6081,37 @@ static void hci_le_conn_update_complete_evt(struct hci_dev *hdev, void *data,
conn->le_conn_interval = le16_to_cpu(ev->interval);
conn->le_conn_latency = le16_to_cpu(ev->latency);
conn->le_supv_timeout = le16_to_cpu(ev->supervision_timeout);
+
+ /* Update stored connection parameters and notify userspace
+ * using the parameters from the original HCI command.
+ */
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_CONN_UPDATE);
+ if (sent) {
+ u8 store_hint;
+
+ params = hci_conn_params_lookup(hdev, &conn->dst,
+ conn->dst_type);
+ if (params) {
+ params->conn_min_interval =
+ le16_to_cpu(sent->conn_interval_min);
+ params->conn_max_interval =
+ le16_to_cpu(sent->conn_interval_max);
+ params->conn_latency =
+ le16_to_cpu(sent->conn_latency);
+ params->supervision_timeout =
+ le16_to_cpu(sent->supervision_timeout);
+ store_hint = 0x01;
+ } else {
+ store_hint = 0x00;
+ }
+
+ mgmt_new_conn_param(hdev, &conn->dst, conn->dst_type,
+ store_hint,
+ le16_to_cpu(sent->conn_interval_min),
+ le16_to_cpu(sent->conn_interval_max),
+ le16_to_cpu(sent->conn_latency),
+ le16_to_cpu(sent->supervision_timeout));
+ }
}
hci_dev_unlock(hdev);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 95c65fece39b..aac2db1d6fbb 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4706,16 +4706,8 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
l2cap_send_cmd(conn, cmd->ident, L2CAP_CONN_PARAM_UPDATE_RSP,
sizeof(rsp), &rsp);
- if (!err) {
- u8 store_hint;
-
- store_hint = hci_le_conn_update(hcon, min, max, latency,
- to_multiplier);
- mgmt_new_conn_param(hcon->hdev, &hcon->dst, hcon->dst_type,
- store_hint, min, max, latency,
- to_multiplier);
-
- }
+ if (!err)
+ hci_le_conn_update(hcon, min, max, latency, to_multiplier);
return 0;
}
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: patchwork-bot+netdevbpf @ 2026-04-13 21:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260413132247.320961-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 13 Apr 2026 09:22:47 -0400 you wrote:
> The following changes since commit 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7:
>
> tools: ynl: tests: fix leading space on Makefile target (2026-04-09 20:41:40 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2026-04-13
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth-next 2026-04-13
https://git.kernel.org/netdev/net-next/c/e9dc62f25ba6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [v4] Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
From: bluez.test.bot @ 2026-04-13 21:24 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260413193212.1014200-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6870 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1080874
---Test result---
Test Summary:
CheckPatch PENDING 0.00 seconds
GitLint PENDING 0.00 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 26.47 seconds
CheckAllWarning PASS 28.73 seconds
CheckSparse PASS 27.39 seconds
BuildKernel32 PASS 25.21 seconds
TestRunnerSetup PASS 564.47 seconds
TestRunner_l2cap-tester PASS 27.72 seconds
TestRunner_iso-tester PASS 37.92 seconds
TestRunner_bnep-tester PASS 6.38 seconds
TestRunner_mgmt-tester FAIL 114.53 seconds
TestRunner_rfcomm-tester PASS 9.44 seconds
TestRunner_sco-tester FAIL 14.03 seconds
TestRunner_ioctl-tester PASS 10.29 seconds
TestRunner_mesh-tester FAIL 11.21 seconds
TestRunner_smp-tester PASS 8.48 seconds
TestRunner_userchan-tester PASS 6.65 seconds
TestRunner_6lowpan-tester FAIL 8.40 seconds
IncrementalBuild PENDING 0.00 seconds
Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:
##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.111 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-ge28a9dbea782 #1 Not tainted
------------------------------------------------------
kworker/u5:2/117 is trying to acquire lock:
ffff88800206b240 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_connect_cfm+0x358/0x8d0
but task is already holding lock:
ffff888002141c20 (&conn->lock){+.+.}-{3:3}, at: sco_connect_cfm+0x22d/0x8d0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&conn->lock){+.+.}-{3:3}:
lock_acquire+0xf7/0x2c0
_raw_spin_lock+0x2a/0x40
sco_sock_connect+0x4d7/0x1280
__sys_connect+0x1a3/0x260
__x64_sys_connect+0x6e/0xb0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
check_prev_add+0xe9/0xc70
__lock_acquire+0x1457/0x1df0
lock_acquire+0xf7/0x2c0
lock_sock_nested+0x36/0xd0
sco_connect_cfm+0x358/0x8d0
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
other info that might help us debug this:
...
BUG: sleeping function called from invalid context at net/core/sock.c:3782
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 117, name: kworker/u5:2
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 117 Comm: kworker/u5:2 Not tainted 7.0.0-rc2-ge28a9dbea782 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x60
__might_resched+0x2ea/0x500
lock_sock_nested+0x47/0xd0
? sco_connect_cfm+0x358/0x8d0
sco_connect_cfm+0x358/0x8d0
? hci_debugfs_create_conn+0x190/0x210
? __pfx_sco_connect_cfm+0x10/0x10
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
? __pfx_hci_sync_conn_complete_evt+0x10/0x10
? __pfx_hci_event_packet+0x10/0x10
? mark_held_locks+0x49/0x80
? lockdep_hardirqs_on_prepare+0xd4/0x180
? _raw_spin_unlock_irqrestore+0x2c/0x50
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
? __pfx_process_scheduled_works+0x10/0x10
? lock_acquire+0xf7/0x2c0
? lock_is_held_type+0x9b/0x110
? __pfx_hci_rx_work+0x10/0x10
worker_thread+0x4ff/0xba0
? _raw_spin_unlock_irqrestore+0x2c/0x50
? __pfx_worker_thread+0x10/0x10
kthread+0x368/0x490
? _raw_spin_unlock_irq+0x23/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork+0x498/0x7e0
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x9e4/0xe50
? __switch_to_asm+0x32/0x60
...
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 1.950 seconds
Mesh - Send cancel - 2 Timed out 2.000 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-ge28a9dbea782 #1 Not tainted
------------------------------------------------------
kworker/0:1/11 is trying to acquire lock:
ffff888002760140 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x75/0x180
but task is already holding lock:
ffffffff9c44d720 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (rtnl_mutex){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
lowpan_register_netdev+0x11/0x30
chan_ready_cb+0x836/0xd00
l2cap_recv_frame+0x6a06/0x8920
l2cap_recv_acldata+0x790/0xdf0
hci_rx_work+0x500/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
-> #3 (&chan->lock#3/1){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
l2cap_chan_connect+0x74e/0x1980
lowpan_control_write+0x523/0x660
full_proxy_write+0x10b/0x190
vfs_write+0x1c0/0xf60
ksys_write+0xf1/0x1d0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #2 (&conn->lock){+.+.}-{4:4}:
...
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:
https://github.com/bluez/bluetooth-next/pull/79
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: l2cap: Fix MPS check in l2cap_ecred_reconf_req
From: bluez.test.bot @ 2026-04-13 21:02 UTC (permalink / raw)
To: linux-bluetooth, phx0fer
In-Reply-To: <20260413085600.75248-1-phx0fer@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6870 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1080587
---Test result---
Test Summary:
CheckPatch PENDING 0.00 seconds
GitLint PENDING 0.00 seconds
SubjectPrefix PASS 0.14 seconds
BuildKernel PASS 27.14 seconds
CheckAllWarning PASS 29.87 seconds
CheckSparse PASS 28.56 seconds
BuildKernel32 PASS 26.53 seconds
TestRunnerSetup PASS 580.32 seconds
TestRunner_l2cap-tester PASS 28.34 seconds
TestRunner_iso-tester PASS 46.27 seconds
TestRunner_bnep-tester PASS 6.43 seconds
TestRunner_mgmt-tester FAIL 115.20 seconds
TestRunner_rfcomm-tester PASS 9.52 seconds
TestRunner_sco-tester FAIL 14.31 seconds
TestRunner_ioctl-tester PASS 10.50 seconds
TestRunner_mesh-tester FAIL 12.22 seconds
TestRunner_smp-tester PASS 8.70 seconds
TestRunner_userchan-tester PASS 6.81 seconds
TestRunner_6lowpan-tester FAIL 8.57 seconds
IncrementalBuild PENDING 0.00 seconds
Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:
##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.107 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gcd52505d5434 #1 Not tainted
------------------------------------------------------
kworker/u5:2/117 is trying to acquire lock:
ffff888001946240 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_connect_cfm+0x358/0x8d0
but task is already holding lock:
ffff888002090c20 (&conn->lock){+.+.}-{3:3}, at: sco_connect_cfm+0x22d/0x8d0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&conn->lock){+.+.}-{3:3}:
lock_acquire+0xf7/0x2c0
_raw_spin_lock+0x2a/0x40
sco_sock_connect+0x4d7/0x1280
__sys_connect+0x1a3/0x260
__x64_sys_connect+0x6e/0xb0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
check_prev_add+0xe9/0xc70
__lock_acquire+0x1457/0x1df0
lock_acquire+0xf7/0x2c0
lock_sock_nested+0x36/0xd0
sco_connect_cfm+0x358/0x8d0
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
other info that might help us debug this:
...
BUG: sleeping function called from invalid context at net/core/sock.c:3782
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 117, name: kworker/u5:2
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 117 Comm: kworker/u5:2 Not tainted 7.0.0-rc2-gcd52505d5434 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x60
__might_resched+0x2ea/0x500
lock_sock_nested+0x47/0xd0
? sco_connect_cfm+0x358/0x8d0
sco_connect_cfm+0x358/0x8d0
? hci_debugfs_create_conn+0x190/0x210
? __pfx_sco_connect_cfm+0x10/0x10
hci_sync_conn_complete_evt+0x3d3/0x8e0
hci_event_packet+0x74f/0xb10
? __pfx_hci_sync_conn_complete_evt+0x10/0x10
? __pfx_hci_event_packet+0x10/0x10
? mark_held_locks+0x49/0x80
? lockdep_hardirqs_on_prepare+0xd4/0x180
? _raw_spin_unlock_irqrestore+0x2c/0x50
hci_rx_work+0x398/0xd00
process_scheduled_works+0xb16/0x1ac0
? __pfx_process_scheduled_works+0x10/0x10
? lock_acquire+0xf7/0x2c0
? lock_is_held_type+0x9b/0x110
? __pfx_hci_rx_work+0x10/0x10
worker_thread+0x4ff/0xba0
? _raw_spin_unlock_irqrestore+0x2c/0x50
? __pfx_worker_thread+0x10/0x10
kthread+0x368/0x490
? _raw_spin_unlock_irq+0x23/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork+0x498/0x7e0
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x9e4/0xe50
? __switch_to_asm+0x32/0x60
...
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.654 seconds
Mesh - Send cancel - 2 Timed out 1.994 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
7.0.0-rc2-gcd52505d5434 #1 Not tainted
------------------------------------------------------
kworker/0:1/14 is trying to acquire lock:
ffff88800275c140 ((wq_completion)hci0#2){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x75/0x180
but task is already holding lock:
ffffffff9a44d720 (rtnl_mutex){+.+.}-{4:4}, at: lowpan_unregister_netdev+0xd/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (rtnl_mutex){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
lowpan_register_netdev+0x11/0x30
chan_ready_cb+0x836/0xd00
l2cap_recv_frame+0x6465/0x8910
l2cap_recv_acldata+0x790/0xdf0
hci_rx_work+0x500/0xd00
process_scheduled_works+0xb16/0x1ac0
worker_thread+0x4ff/0xba0
kthread+0x368/0x490
ret_from_fork+0x498/0x7e0
ret_from_fork_asm+0x19/0x30
-> #3 (&chan->lock#3/1){+.+.}-{4:4}:
lock_acquire+0xf7/0x2c0
__mutex_lock+0x16b/0x1fc0
l2cap_chan_connect+0x74e/0x1980
lowpan_control_write+0x523/0x660
full_proxy_write+0x10b/0x190
vfs_write+0x1c0/0xf60
ksys_write+0xf1/0x1d0
do_syscall_64+0xa0/0x570
entry_SYSCALL_64_after_hwframe+0x74/0x7c
-> #2 (&conn->lock){+.+.}-{4:4}:
...
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:
https://github.com/bluez/bluetooth-next/pull/78
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-10
From: Jakub Kicinski @ 2026-04-13 20:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <CABBYNZLg_Dz9ieQ+ioXf2+Oa+vdL8BMbnt=qOfkONOpNsUZ5qw@mail.gmail.com>
On Mon, 13 Apr 2026 16:07:55 -0400 Luiz Augusto von Dentz wrote:
> > Two fixes tags are messed up here:
> >
> > Commit: 802446198014 ("Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array")
> > Fixes tag: Fixes: 4cdd001ff03f ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > Commit: 28c9cc700e30 ("Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU")
> > Fixes tag: Fixes: fa768fce4aae ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU")
> > Has these problem(s):
> > - Target SHA1 does not exist
>
> Would you be able to pull the for-net-next-2026-04-13?
I think so.
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-10
From: Luiz Augusto von Dentz @ 2026-04-13 20:07 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <20260412091614.1786af4e@kernel.org>
Hi Jakub
On Sun, Apr 12, 2026 at 12:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 10 Apr 2026 13:22:06 -0400 Luiz Augusto von Dentz wrote:
> > bluetooth-next pull request for net-next:
> >
> > core:
> > - hci_core: Rate limit the logging of invalid ISO handle
> > - hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists
> > - hci_event: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER
> > - hci_event: fix potential UAF in SSP passkey handlers
> > - HCI: Avoid a couple -Wflex-array-member-not-at-end warnings
> > - L2CAP: CoC: Disconnect if received packet size exceeds MPS
> > - L2CAP: Add missing chan lock in l2cap_ecred_reconf_rsp
> > - L2CAP: Fix printing wrong information if SDU length exceeds MTU
> > - SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec
> >
> > drivers:
> > - btusb: MT7922: Add VID/PID 0489/e174
> > - btusb: Add Lite-On 04ca:3807 for MediaTek MT7921
> > - btusb: Add MT7927 IDs ASUS ROG Crosshair X870E Hero, Lenovo Legion Pro 7
> > 16ARX9, Gigabyte Z790 AORUS MASTER X, MSI X870E Ace Max, TP-Link
> > Archer TBE550E, ASUS X870E / ProArt X870E-Creator.
> > - btusb: Add MT7902 IDs 13d3/3579, 13d3/3580, 13d3/3594, 13d3/3596, 0e8d/1ede
> > - btusb: MediaTek MT7922: Add VID 0489 & PID e11d
> > - btintel: Add support for Scorpious Peak2 support
> > - btintel: Add support for Scorpious Peak2F support
> > - btintel_pcie: Add device id of Scorpius Peak2, Nova Lake-PCD-H
> > - btintel_pcie: Add device id of Scorpious2, Nova Lake-PCD-S
> > - btmtk: Add reset mechanism if downloading firmware failed
> > - btmtk: Add MT6639 (MT7927) Bluetooth support
> > - btmtk: fix ISO interface setup for single alt setting
> > - btmtk: add MT7902 SDIO support
> > - Bluetooth: btmtk: add MT7902 MCU support
> > - btbcm: Add entry for BCM4343A2 UART Bluetooth
> > - qca: enable pwrseq support for wcn39xx devices
> > - hci_qca: Fix BT not getting powered-off on rmmod
> > - hci_qca: disable power control for WCN7850 when bt_en is not defined
> > - hci_qca: Fix missing wakeup during SSR memdump handling
> > - hci_ldisc: Clear HCI_UART_PROTO_INIT on error
> > - mmc: sdio: add MediaTek MT7902 SDIO device ID
> > - hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x
>
> Two fixes tags are messed up here:
>
> Commit: 802446198014 ("Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array")
> Fixes tag: Fixes: 4cdd001ff03f ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
> Has these problem(s):
> - Target SHA1 does not exist
>
> Commit: 28c9cc700e30 ("Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU")
> Fixes tag: Fixes: fa768fce4aae ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU")
> Has these problem(s):
> - Target SHA1 does not exist
Would you be able to pull the for-net-next-2026-04-13?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: btintel_pcie: Support Product level reset
From: patchwork-bot+bluetooth @ 2026-04-13 20:00 UTC (permalink / raw)
To: Chandrashekar Devegowda
Cc: linux-bluetooth, linux-pci, bhelgaas, ravishankar.srivatsa,
chethan.tumkur.narayan
In-Reply-To: <20260413042041.1318723-1-chandrashekar.devegowda@intel.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 13 Apr 2026 09:50:40 +0530 you wrote:
> When driver encounters a TOP exception, ACPI methods will be called
> for Product level reset since Wifi and BT share the same TOP. BT driver
> will first reprobe the wifi driver and then reprobe BT.
>
> Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
> ---
>
> [...]
Here is the summary with links:
- [v3] Bluetooth: btintel_pcie: Support Product level reset
https://git.kernel.org/bluetooth/bluetooth-next/c/912a499a7955
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-13 19:54 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1080317
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-13 19:54 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1080516
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] fb0f8f: audio/player: Ensure metadata string is valid UTF-8
From: Pauli Virtanen @ 2026-04-13 19:53 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: fb0f8f495ace893f65ee1eaa91e84743ccf62cc9
https://github.com/bluez/bluez/commit/fb0f8f495ace893f65ee1eaa91e84743ccf62cc9
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-04-13 (Mon, 13 Apr 2026)
Changed paths:
M profiles/audio/player.c
Log Message:
-----------
audio/player: Ensure metadata string is valid UTF-8
bluetoothd crashes on reception of GetItemAttributes reply if it contains
an invalid UTF-8 string:
> BR-ACL: Handle 11 [B8:3C:28:E8:07:69 (Apple, Inc.)] flags 0x02 dlen 680
Channel: 71 len 676 ctrl 0x0304 [PSM 27 mode Enhanced Retransmission
(0x03)] {chan 7}
I-frame: Unsegmented TxSeq 2 ReqSeq 3
AVCTP Browsing: Response: type 0x00 label 2 PID 0x110e
AVRCP: GetItemAttributes: len 0x029a
Status: 0x04 (Success)
AttributeCount: 0x01 (1)
AttributeID: 0x00000001 (Title)
CharsetID: 0x006a (UTF-8)
AttributeLength: 0x0290 (656)
AttributeValue: ................................................
..........................................................................
.........................................................................2
009.......................................................................
..........................................................................
..........................................................................
..........................................................................
..........................................................................
..........................................................................
................
= bluetoothd: profiles/audio/player.c:media_player_set_playlist_item() 0
= bluetoothd: profiles/audio/player.c:media_player_set_metadata() Title:
奥巴马表示：美国之所以没有搞定中国，不是因为中国的军事实力以及经济强大
，而是因为中国从始至终都没有掉进我们安排的“陷阱”。时间倒回2009年，北京
钓鱼台国宾馆。奥巴马的随行团队一进门，连句客套话都没顾得上说，反手就把
随身带的电子设备挨个拔了电源、卸了电池。这阵仗看着像是在防监听，实则是
心虚。那群在长桌对面坐下的人，心里正翻腾着一种从未有过的无力感。因为眼
前的谈判对象，压根没打算照着他们兜里的剧本念台词。多年以后，退下来的奥
巴马在回忆录《应�
arguments to dbus_message_iter_append_basic() were incorrect,
assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file
dbus-message.c line 2775.
This is normally a bug in some application using the D-Bus library.
Commit: 1ab128f6d749427a5508592b3b2b587b724efccf
https://github.com/bluez/bluez/commit/1ab128f6d749427a5508592b3b2b587b724efccf
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-04-13 (Mon, 13 Apr 2026)
Changed paths:
M src/gatt-database.c
Log Message:
-----------
gatt-database: remove database from dbs list when destroyed
btd_gatt_database_new() adds btd_gatt_database to the dbs lookup queue,
but nothing removes it from there even when destroying.
Fix by removing databases from the lookup queue before destroy.
Fixes crash on adapter removal in some cases:
ERROR: AddressSanitizer: heap-use-after-free on address 0x7bd476be1308
READ of size 8 at 0x7bd476be1308 thread T0
#0 0x00000064562a in match_db
#1 0x000000865410 in queue_find
#2 0x000000645671 in btd_gatt_database_get
0x7bd476be1308 is located 8 bytes inside of 128-byte region [0x7bd476be1300,0x7bd476be>
freed by thread T0 here:
#0 0x7f1478cee4cf in free.part.0
#1 0x000000621625 in gatt_database_free
#2 0x000000645582 in btd_gatt_database_destroy
Compare: https://github.com/bluez/bluez/compare/516099a9d405...1ab128f6d749
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
From: Luiz Augusto von Dentz @ 2026-04-13 19:45 UTC (permalink / raw)
To: Mikhail Gavrilov; +Cc: marcel, pmenzel, linux-bluetooth, linux-kernel
In-Reply-To: <20260410063001.94728-1-mikhail.v.gavrilov@gmail.com>
Hi Mikhail,
On Fri, Apr 10, 2026 at 2:30 AM Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> When a BLE peripheral sends an L2CAP Connection Parameter Update Request
> the processing path is:
>
> process_pending_rx() [takes conn->lock]
> l2cap_le_sig_channel()
> l2cap_conn_param_update_req()
> hci_le_conn_update() [takes hdev->lock]
>
> Meanwhile other code paths take the locks in the opposite order:
>
> l2cap_chan_connect() [takes hdev->lock]
> ...
> mutex_lock(&conn->lock)
>
> l2cap_conn_ready() [hdev->lock via hci_cb_list_lock]
> ...
> mutex_lock(&conn->lock)
>
> This is a classic AB/BA deadlock which lockdep reports as a circular
> locking dependency when connecting a BLE MIDI keyboard (Carry-On FC-49).
>
> Fix this by introducing l2cap_conn_param_update_sync() which is scheduled
> via hci_cmd_sync_queue() to run on the hci_cmd_sync workqueue, outside
> any of the involved locks. The necessary connection parameters are
> captured into a heap-allocated struct conn_param_update_data and the
> sync callback performs the hci_conn_params update, sends the HCI LE
> Connection Update command, and notifies mgmt of the new parameters.
>
> To guard against a theoretical handle-reuse race (the connection could
> drop and its handle be reassigned between queuing and execution), the
> sync callback verifies the connection still exists and its destination
> address matches the original request before proceeding.
>
> The allocation is performed before sending the L2CAP_CONN_PARAM_ACCEPTED
> response so that on OOM the peer receives a REJECTED response instead of
> an inconsistent state where the peer applies new parameters but the local
> controller does not.
>
> Fixes: f044eb0524a0 ("Bluetooth: Store latency and supervision timeout in connection params")
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> ---
>
> Changes in v2 (Paul Menzel, Sashiko/Gemini AI review):
> - Allocate before sending ACCEPTED response to avoid state mismatch on OOM
> - Verify connection handle and address in sync callback against reuse race
> - Expand commit message with implementation details
>
> net/bluetooth/l2cap_core.c | 93 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 85 insertions(+), 8 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 95c65fece39b..94dfef9df498 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4670,6 +4670,70 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn,
> return 0;
> }
>
> +struct conn_param_update_data {
> + u16 handle;
> + bdaddr_t dst;
> + u8 dst_type;
> + u16 min;
> + u16 max;
> + u16 latency;
> + u16 to_multiplier;
> +};
> +
> +static int l2cap_conn_param_update_sync(struct hci_dev *hdev, void *data)
> +{
> + struct conn_param_update_data *d = data;
> + struct hci_conn *conn;
> + struct hci_conn_params *params;
> + struct hci_cp_le_conn_update cp;
> + u8 store_hint = 0x00;
> +
> + /* Verify the connection is still alive and matches the original
> + * request, since the handle could theoretically be reused after
> + * a disconnect/reconnect cycle.
> + */
> + hci_dev_lock(hdev);
> +
> + conn = hci_conn_hash_lookup_handle(hdev, d->handle);
> + if (!conn || bacmp(&conn->dst, &d->dst)) {
> + hci_dev_unlock(hdev);
> + return 0;
> + }
> +
> + params = hci_conn_params_lookup(hdev, &d->dst, d->dst_type);
> + if (params) {
> + params->conn_min_interval = d->min;
> + params->conn_max_interval = d->max;
> + params->conn_latency = d->latency;
> + params->supervision_timeout = d->to_multiplier;
> + store_hint = 0x01;
> + }
> +
> + hci_dev_unlock(hdev);
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.handle = cpu_to_le16(d->handle);
> + cp.conn_interval_min = cpu_to_le16(d->min);
> + cp.conn_interval_max = cpu_to_le16(d->max);
> + cp.conn_latency = cpu_to_le16(d->latency);
> + cp.supervision_timeout = cpu_to_le16(d->to_multiplier);
> + cp.min_ce_len = cpu_to_le16(0x0000);
> + cp.max_ce_len = cpu_to_le16(0x0000);
> +
> + hci_send_cmd(hdev, HCI_OP_LE_CONN_UPDATE, sizeof(cp), &cp);
> +
> + mgmt_new_conn_param(hdev, &d->dst, d->dst_type, store_hint,
> + d->min, d->max, d->latency, d->to_multiplier);
Actually most of this can be defered directly to
hci_event.c:hci_le_conn_update_complete_evt, then use
hci_sent_cmd_data(hdev, HCI_OP_LE_CONN_UPDATE) to fetch the command
parameters.
> +
> + return 0;
> +}
> +
> +static void l2cap_conn_param_update_destroy(struct hci_dev *hdev, void *data,
> + int err)
> +{
> + kfree(data);
> +}
> +
> static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
> struct l2cap_cmd_hdr *cmd,
> u16 cmd_len, u8 *data)
> @@ -4677,6 +4741,7 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
> struct hci_conn *hcon = conn->hcon;
> struct l2cap_conn_param_update_req *req;
> struct l2cap_conn_param_update_rsp rsp;
> + struct conn_param_update_data *d;
> u16 min, max, latency, to_multiplier;
> int err;
>
> @@ -4703,18 +4768,30 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
> else
> rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_ACCEPTED);
>
> + if (!err) {
> + d = kmalloc(sizeof(*d), GFP_KERNEL);
> + if (!d) {
> + rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
> + err = -ENOMEM;
> + }
> + }
> +
> l2cap_send_cmd(conn, cmd->ident, L2CAP_CONN_PARAM_UPDATE_RSP,
> sizeof(rsp), &rsp);
>
> if (!err) {
> - u8 store_hint;
> -
> - store_hint = hci_le_conn_update(hcon, min, max, latency,
> - to_multiplier);
> - mgmt_new_conn_param(hcon->hdev, &hcon->dst, hcon->dst_type,
> - store_hint, min, max, latency,
> - to_multiplier);
Just make hci_le_conn_update internally use hci_cmd_sync_queue and
then handle the update values at hci_le_conn_update_complete_evt.
> -
> + d->handle = hcon->handle;
> + bacpy(&d->dst, &hcon->dst);
> + d->dst_type = hcon->dst_type;
> + d->min = min;
> + d->max = max;
> + d->latency = latency;
> + d->to_multiplier = to_multiplier;
> +
> + if (hci_cmd_sync_queue(hcon->hdev,
> + l2cap_conn_param_update_sync, d,
> + l2cap_conn_param_update_destroy) < 0)
> + kfree(d);
> }
>
> return 0;
> --
> 2.53.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v4] Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
From: Luiz Augusto von Dentz @ 2026-04-13 19:32 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for
a BIG handle using a while loop, accessing ev->bis_handle[i++] on each
iteration. However, there is no check that i stays within ev->num_bis
before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer
bis_handle entries than there are BT_BOUND connections for that BIG,
or with num_bis=0, the loop reads beyond the valid bis_handle[] flex
array into adjacent heap memory. Since the out-of-bounds values
typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()
rejects them and the connection remains in BT_BOUND state. The same
connection is then found again by hci_conn_hash_lookup_big_state(),
creating an infinite loop with hci_dev_lock held.
Fix this by terminating the BIG if in case not all BIS could be setup
properly.
Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes")
Cc: stable@vger.kernel.org
Signed-off-by: ZhiTao Ou <hkbinbinbin@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index b2ee6b6a0f56..cd4160f741b4 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -7118,9 +7118,29 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
continue;
}
+ if (ev->num_bis <= i) {
+ bt_dev_err(hdev,
+ "Not enough BIS handles for BIG 0x%2.2x",
+ ev->handle);
+ ev->status = HCI_ERROR_UNSPECIFIED;
+ hci_connect_cfm(conn, ev->status);
+ hci_conn_del(conn);
+ break;
+ }
+
if (hci_conn_set_handle(conn,
- __le16_to_cpu(ev->bis_handle[i++])))
+ __le16_to_cpu(ev->bis_handle[i++]))) {
+ bt_dev_err(hdev,
+ "Failed to set BIS handle for BIG 0x%2.2x",
+ ev->handle);
+ /* Force error so BIG gets terminated as not all BIS
+ * could be connected.
+ */
+ ev->status = HCI_ERROR_UNSPECIFIED;
+ hci_connect_cfm(conn, ev->status);
+ hci_conn_del(conn);
continue;
+ }
conn->state = BT_CONNECTED;
set_bit(HCI_CONN_BIG_CREATED, &conn->flags);
@@ -7129,7 +7149,10 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
hci_iso_setup_path(conn);
}
- if (!ev->status && !i)
+ /* If there is an unexpected error or if no BISes have been connected
+ * for the BIG, terminate it.
+ */
+ if (ev->status == HCI_ERROR_UNSPECIFIED || (!ev->status && !i))
/* If no BISes have been connected for the BIG,
* terminate. This is in case all bound connections
* have been closed before the BIG creation
--
2.53.0
^ permalink raw reply related
* Re: [PATCH BlueZ] audio/player: Ensure metadata string is valid UTF-8
From: patchwork-bot+bluetooth @ 2026-04-13 19:00 UTC (permalink / raw)
To: =?utf-8?b?RnLDqWTDqXJpYyBEYW5pcyA8ZnJlZGVyaWMuZGFuaXNAY29sbGFib3JhLmNvbT4=?=
Cc: linux-bluetooth
In-Reply-To: <20260413071246.19221-1-frederic.danis@collabora.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 13 Apr 2026 09:12:46 +0200 you wrote:
> bluetoothd crashes on reception of GetItemAttributes reply if it contains
> an invalid UTF-8 string:
>
> > BR-ACL: Handle 11 [B8:3C:28:E8:07:69 (Apple, Inc.)] flags 0x02 dlen 680
> Channel: 71 len 676 ctrl 0x0304 [PSM 27 mode Enhanced Retransmission
> (0x03)] {chan 7}
> I-frame: Unsegmented TxSeq 2 ReqSeq 3
> AVCTP Browsing: Response: type 0x00 label 2 PID 0x110e
> AVRCP: GetItemAttributes: len 0x029a
> Status: 0x04 (Success)
> AttributeCount: 0x01 (1)
> AttributeID: 0x00000001 (Title)
> CharsetID: 0x006a (UTF-8)
> AttributeLength: 0x0290 (656)
> AttributeValue: ................................................
> ..........................................................................
> .........................................................................2
> 009.......................................................................
> ..........................................................................
> ..........................................................................
> ..........................................................................
> ..........................................................................
> ..........................................................................
> ................
> = bluetoothd: profiles/audio/player.c:media_player_set_playlist_item() 0
> = bluetoothd: profiles/audio/player.c:media_player_set_metadata() Title:
> 奥巴马表示：美国之所以没有搞定中国，不是因为中国的军事实力以及经济强大
> ，而是因为中国从始至终都没有掉进我们安排的“陷阱”。时间倒回2009年，北京
> 钓鱼台国宾馆。奥巴马的随行团队一进门，连句客套话都没顾得上说，反手就把
> 随身带的电子设备挨个拔了电源、卸了电池。这阵仗看着像是在防监听，实则是
> 心虚。那群在长桌对面坐下的人，心里正翻腾着一种从未有过的无力感。因为眼
> 前的谈判对象，压根没打算照着他们兜里的剧本念台词。多年以后，退下来的奥
> 巴马在回忆录《应�
> arguments to dbus_message_iter_append_basic() were incorrect,
> assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file
> dbus-message.c line 2775.
> This is normally a bug in some application using the D-Bus library.
>
> [...]
Here is the summary with links:
- [BlueZ] audio/player: Ensure metadata string is valid UTF-8
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=fb0f8f495ace
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ] gatt-database: remove database from dbs list when destroyed
From: patchwork-bot+bluetooth @ 2026-04-13 19:00 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <3806351a2fbd1b5e463c9530203f7d121f673f61.1775992233.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 12 Apr 2026 14:11:30 +0300 you wrote:
> btd_gatt_database_new() adds btd_gatt_database to the dbs lookup queue,
> but nothing removes it from there even when destroying.
>
> Fix by removing databases from the lookup queue before destroy.
>
> Fixes crash on adapter removal in some cases:
>
> [...]
Here is the summary with links:
- [BlueZ] gatt-database: remove database from dbs list when destroyed
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=1ab128f6d749
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready
From: patchwork-bot+bluetooth @ 2026-04-13 18:20 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <9f333a79da3f0f552ca735d549ea3e8ae0784220.1776019593.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 12 Apr 2026 21:47:42 +0300 you wrote:
> sco_conn_ready calls sleeping functions under conn->lock spinlock.
>
> The critical section can be reduced: conn->hcon is modified only with
> hdev->lock held. It is guaranteed to be held in sco_conn_ready, so
> conn->lock is not needed to guard it.
>
> Move taking conn->lock after lock_sock(parent). This also follows the
> lock ordering lock_sock() > conn->lock elsewhere in the file.
>
> [...]
Here is the summary with links:
- Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready
https://git.kernel.org/bluetooth/bluetooth-next/c/d87bd74aeb54
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4] Bluetooth: hci_conn: fix potential UAF in create_big_sync
From: patchwork-bot+bluetooth @ 2026-04-13 18:20 UTC (permalink / raw)
To: David Carlier
Cc: marcel, luiz.dentz, pav, linux-bluetooth, linux-kernel, stable,
luiz.von.dentz
In-Reply-To: <20260412202916.196282-1-devnexen@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 12 Apr 2026 21:29:16 +0100 you wrote:
> Add hci_conn_valid() check in create_big_sync() to detect stale
> connections before proceeding with BIG creation. Handle the
> resulting -ECANCELED in create_big_complete() and re-validate the
> connection under hci_dev_lock() before dereferencing, matching the
> pattern used by create_le_conn_complete() and create_pa_complete().
>
> Keep the hci_conn object alive across the async boundary by taking
> a reference via hci_conn_get() when queueing create_big_sync(), and
> dropping it in the completion callback. The refcount and the lock
> are complementary: the refcount keeps the object allocated, while
> hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on
> hdev->conn_hash, as required by hci_conn_del().
>
> [...]
Here is the summary with links:
- [v4] Bluetooth: hci_conn: fix potential UAF in create_big_sync
https://git.kernel.org/bluetooth/bluetooth-next/c/d55d107b6fa6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox