** Description changed:
Package: linux (Ubuntu), Noble
Affected: 6.8.0-148.148 (proposed2, tracker LP: #2170052)
Last good: 6.8.0-147.147 (noble-updates)
## [Impact]
On 6.8.0-148.148, no Bluetooth ACL, SCO or ISO data packet is ever sent by
the host once the adapter has been powered on. HCI commands and events still
work, so discovery, paging, pairing, authentication and encryption all
succeed. Every profile connection then fails: A2DP, OBEX/RFCOMM, SDP, and
anything else that runs over L2CAP.
The kernel does not even answer the peer's L2CAP Information Request, which
is generated in-kernel. The remote side therefore tears the link down after
`L2CAP_INFO_TIMEOUT` (4 s). dmesg reports nothing.
This is a deterministic regression. Every BR/EDR data connection is affected,
on any controller.
## Root cause
Ubuntu's 6.8 backport of upstream commit 525daaea459f ("Bluetooth: hci_sync:
Set HCI_CMD_DRAIN_WORKQUEUE during device close"), introduced in
6.8.0-146.146, applied its first hunk to the wrong function. The hunk's
context (`bt_dev_dbg(hdev, "");` followed by a blank line) matches the start
of both `hci_dev_open_sync()` and `hci_dev_close_sync()`, so the set ended up
in `hci_dev_open_sync()`:
```c
int hci_dev_open_sync(struct hci_dev *hdev)
{
- int ret;
+ int ret;
- bt_dev_dbg(hdev, "");
+ bt_dev_dbg(hdev, "");
- /* Set HCI_DRAIN_WORKQUEUE flag to prevent queuing work during
- * reset/close. See hci_cmd_work() and handle_cmd_cnt_and_timer().
- */
- hci_dev_set_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE); /* <-- upstream has
this in hci_dev_close_sync() */
- synchronize_rcu();
+ /* Set HCI_DRAIN_WORKQUEUE flag to prevent queuing work during
+ * reset/close. See hci_cmd_work() and handle_cmd_cnt_and_timer().
+ */
+ hci_dev_set_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE); /* <-- upstream has this
in hci_dev_close_sync() */
+ synchronize_rcu();
```
The matching `hci_dev_clear_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)` calls were
applied correctly inside `hci_dev_close_sync()`. As a result,
`HCI_CMD_DRAIN_WORKQUEUE` is **set on every power-on and stays set while the
adapter is up**.
- In 6.8.0-146/147 this was latent. The flag only suppresses arming
- `hdev->cmd_timer`, so HCI command-timeout detection is silently disabled
- while the adapter is up.
+ `hdev->cmd_timer`, so HCI command-timeout detection is silently disabled
+ while the adapter is up.
- 6.8.0-148.148 adds upstream 6610c6fe4b89 ("Bluetooth: hci_core: Fix
- queuing tx_work after workqueue is drained", CVE-2026-98297), which now
gates
- `hdev->tx_work` on the same flag:
+ queuing tx_work after workqueue is drained", CVE-2026-98297), which now
gates
+ `hdev->tx_work` on the same flag:
- ```c
- static void hci_sched_tx(struct hci_dev *hdev)
- {
- rcu_read_lock();
- if (!hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE))
- queue_work(hdev->workqueue, &hdev->tx_work);
- rcu_read_unlock();
- }
- ```
+ ```c
+ static void hci_sched_tx(struct hci_dev *hdev)
+ {
+ rcu_read_lock();
+ if (!hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE))
+ queue_work(hdev->workqueue, &hdev->tx_work);
+ rcu_read_unlock();
+ }
+ ```
- Because the flag is always set while the device is up, `hci_send_acl()`,
- `hci_send_sco()` and `hci_send_iso()` queue skbs to `conn->data_q` but never
- schedule `tx_work`. Nothing is ever transmitted.
+ Because the flag is always set while the device is up, `hci_send_acl()`,
+ `hci_send_sco()` and `hci_send_iso()` queue skbs to `conn->data_q` but never
+ schedule `tx_work`. Nothing is ever transmitted.
Upstream (and the 6.6.y/6.12.y/6.18.y backports) set the flag at the start of
`hci_dev_close_sync()`, not in `hci_dev_open_sync()`.
## [Fix]
Move the misplaced hunk from `hci_dev_open_sync()` to the start of
`hci_dev_close_sync()`, matching upstream 525daaea459f (patch attached:
`0001-UBUNTU-SAUCE-Bluetooth-hci_sync-move-HCI_CMD_DRAIN_WORKQUEUE-set-to-close.patch`).
Equivalently, revert the Ubuntu backport of 525daaea459f and re-apply it
cleanly. Also confirm the other kernels that took the same stable patchset
(derivatives and HWE) are free of the same misapply.
## [Test Plan]
1. Boot the affected kernel with any Bluetooth adapter.
2. Connect to any BR/EDR peer profile, for example `bluetoothctl connect
- <A2DP sink>` or `obexctl`/`obexput -b <addr> <file>`.
+ <A2DP sink>` or `obexctl`/`obexput -b <addr> <file>`.
3. Run `btmon`. On the broken kernel the host emits **zero** `ACL Data TX`
- frames, and peer `L2CAP: Information Request` frames get no response.
- On the fixed kernel, Information Response, Connection Request and
- Configure Request are sent and the profile connects.
+ frames, and peer `L2CAP: Information Request` frames get no response.
+ On the fixed kernel, Information Response, Connection Request and
+ Configure Request are sent and the profile connects.
- Automated reproducer: Checkbox jobs `bluetooth/zapper-a2dp` and
- `bluetooth/zapper-obex` (checkbox-provider-zapper), run against a Zapper
- test fixture.
+ Automated reproducer: Checkbox jobs `bluetooth/a2dp` and
+ `bluetooth/obex` (checkbox-provider), run against a test fixture.
## Evidence (A/B on the same DUT, same BlueZ 5.72-0ubuntu5.8, same peer)
| | 6.8.0-147.147 | 6.8.0-148.148 |
|---|---|---|
| A2DP connect | PASS | FAIL (`br-connection-unknown` ×5, AVDTP `Connection
reset by peer`) |
| OBEX send/browse/get/remove | PASS | FAIL (pair OK, `obexput` cannot
connect) |
| DUT `ACL Data TX` frames in btmon | 156 | **0** |
| ACL frames received by the peer from the DUT | 155 | **0** |
| Peer L2CAP Information Requests answered | yes | **no** (16 sent, 0
answered) |
The same result reproduced on two separate installs/boots of 148. Rolling
back to 147 restores PASS both times.
- DUT: HP ProDesk 400 G6 Desktop Mini, Intel AX201 Bluetooth (8087:0026,
- btusb/btintel, fw `ibt-19-0-4`)
+ btusb/btintel, fw `ibt-19-0-4`)
- Peer: Raspberry Pi 4 (BCM4345C0) running BlueZ 5.72 as A2DP sink / OBEX
server
Attached: btsnoop traces (DUT and peer, both kernels), dmesg, journals,
direct test logs, the 147→148 Bluetooth source diff, and the proposed patch.
Attachments:
C3 submission contains all results and attachments:
https://certification.canonical.com/hardware/202005-27942/submission/517507/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2171926
Title:
6.8.0-148.148: Bluetooth BR/EDR ACL data is never transmitted
(A2DP/OBEX/RFCOMM broken)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/2171926/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
