* Re: [PATCH v6 1/2] dt-bindings: net: bluetooth: Add brcm,bcm4384-bt
From: Krzysztof Kozlowski @ 2026-05-20 11:19 UTC (permalink / raw)
To: kaihsin Chung, linux-bluetooth
Cc: marcel, luiz.von.dentz, linux-kernel, Kaihsin Chung
In-Reply-To: <20260520090131.3505676-2-kaihsin.chung@synaptics.com>
On 20/05/2026 11:01, kaihsin Chung wrote:
> From: Kaihsin Chung <kaihsin.chung@synaptics.com>
>
> Add the compatible string for the Broadcom BCM4384
> Bluetooth controller.
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.
You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.
Please kindly resend and include all necessary To/Cc entries.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>
> Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
> ---
> .../bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> index 37cb39a3a62e..139d9b47329c 100644
> --- a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> +++ b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> @@ -23,7 +23,7 @@ properties:
> - pci14e4,5fa0 # BCM4377
> - pci14e4,5f69 # BCM4378
> - pci14e4,5f71 # BCM4387
> -
Why?
> + - brcm,bcm4384-bt
> reg:
> maxItems: 1
>
I really doubt you tested it. What sort of bus is used for your device?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.18] Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Aurelien DESBRIERES, syzbot+ff30eeab8e07b37d524e,
Luiz Augusto von Dentz, Sasha Levin, marcel, luiz.dentz,
linux-bluetooth, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Aurelien DESBRIERES <aurelien@hackers.camp>
[ Upstream commit 902fe40bce7059722f7ffa1c378e577675cf1918 ]
When a fault is injected during hci_uart line discipline setup, the
proto open() callback may fail leaving hu->priv as NULL. A subsequent
TIOCSTI ioctl can trigger the recv() callback before priv is
initialized, causing a NULL pointer dereference.
Fix all four affected HCI UART protocol drivers by adding a NULL check
on hu->priv at the start of their recv() callbacks: h4, h5, ath and
bcsp.
Reported-by: syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e
Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `Bluetooth: hci_uart`; action verb `Fix`;
intent is to prevent NULL dereference in HCI UART protocol `recv()`
callbacks when `hu->priv` is not initialized.
Step 1.2 Record: Tags found: `Reported-by:
syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com`; `Closes:
https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e`; `Signed-
off-by: Aurelien DESBRIERES`; `Assisted-by: Claude:claude-sonnet-4-6`;
`Signed-off-by: Luiz Augusto von Dentz`. No `Fixes:` tag. Notable
pattern: syzbot report with reproducer and KASAN NULL-deref crash.
Step 1.3 Record: The commit describes a `hu->priv == NULL` path during
HCI UART setup followed by received data via `TIOCSTI`, causing a NULL
pointer dereference. The syzkaller report verifies a KASAN NULL-
deref/general protection fault in `h4_recv`, with call chain `tty_ioctl
-> tiocsti -> hci_uart_tty_receive -> h4_recv`.
Step 1.4 Record: This is not hidden cleanup; it is an explicit memory-
safety crash fix. The added checks prevent dereferencing protocol-
private state when setup/error handling leaves it absent.
## Phase 2: Diff Analysis
Step 2.1 Record: Four files changed, all in `drivers/bluetooth`:
`hci_ath.c` `+3/-0`, `hci_bcsp.c` `+3/-0`, `hci_h4.c` `+3/-0`,
`hci_h5.c` `+3/-0`; total `12` insertions. Modified functions:
`ath_recv`, `bcsp_recv`, `h4_recv`, `h5_recv`. Scope: small multi-file
surgical driver fix.
Step 2.2 Record: Each hunk previously assigned `hu->priv` to a protocol-
private pointer and then dereferenced it. After the patch, each callback
returns `-ENODEV` if that pointer is NULL. The affected path is receive
handling through the HCI UART line discipline, including data injected
by `TIOCSTI`.
Step 2.3 Record: Bug category is NULL pointer dereference / memory
safety. Specific mechanism: `hci_uart_tty_receive()` calls
`hu->proto->recv()`, and these callbacks dereference `hu->priv`; if
setup/error handling leaves `hu->priv` NULL, the callback crashes. The
fix adds direct NULL guards before first dereference.
Step 2.4 Record: Fix quality is high: simple, local, obviously correct,
no API/data structure changes. Regression risk is very low; it only
changes an invalid crash path to `-ENODEV`.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the vulnerable lines showed the current
callback bodies come from long-standing Bluetooth UART code, with recent
edits such as `b489556a856d` for `h4_recv_buf()` usage and
`ca94b2b036c2` adding the BCSP registered guard. The vulnerable pattern
exists in `v6.19.14` and `v7.0.5`.
Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow.
Step 3.3 Record: Related recent commits include `0ffac654e95c` / stable
backport `981b4fd2baf3` removing the `HCI_UART_REGISTERED` guard from
`h4_recv`, and `0c3cd7a0b862` fixing a related HCI UART NULL deref in
write work. Another related upstream commit, `68d39ea5e0ad`, clears
`HCI_UART_PROTO_INIT` on register error but is present in `v7.1-rc*`,
not in checked `v6.19.14`/`v7.0.5`.
Step 3.4 Record: No prior Bluetooth commits by Aurelien DESBRIERES were
found in this checkout. The patch was committed/applied by Bluetooth
maintainer Luiz Augusto von Dentz.
Step 3.5 Record: No functional prerequisite is required for this patch
in affected trees; it applies cleanly to current `v7.0.5`. It is most
relevant to trees with the `HCI_UART_PROTO_INIT` receive path and the
recent H4 initialization-race changes, such as checked `v6.19.y` and
`v7.0.y`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 902fe40bce70` found the original thread:
`https://patch.msgid.link/20260421135331.15425-1-aurelien@hackers.camp`.
`b4 dig -a` found only v1; the committed patch matches the submitted
revision.
Step 4.2 Record: `b4 dig -w` showed recipients included `linux-
bluetooth`, Marcel Holtmann, Johan Hedberg, Luiz Dentz, `linux-kernel`,
and syzbot. The patchwork bot reported it was applied to
`bluetooth/bluetooth-next.git` by Luiz Augusto von Dentz.
Step 4.3 Record: Syzkaller bug page verifies: “general protection fault
in h4_recv”, KASAN NULL-ptr-deref, C and syz reproducers, and fix commit
`902fe40bce70`.
Step 4.4 Record: No multi-patch series was found; only v1 of this one-
patch submission.
Step 4.5 Record: Direct lore stable fetch was blocked by Anubis; web
search found no stable-specific discussion. This does not affect the
decision because the syzbot crash and code path are verified elsewhere.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified functions: `ath_recv`, `bcsp_recv`, `h4_recv`,
`h5_recv`.
Step 5.2 Record: Exact call path verified: protocol structs assign
`.recv = h4_recv/ath_recv/bcsp_recv/h5_recv`; `hci_uart_tty_receive()`
calls `hu->proto->recv(hu, data, count)`; `tiocsti()` calls the line
discipline `receive_buf`.
Step 5.3 Record: Key callees include `h4_recv_buf()`,
`hci_recv_frame()`, `h5_reset_rx()`, `bcsp_unslip_one_byte()`, and skb
cleanup helpers. The first unsafe operation in each changed function was
a dereference of the private pointer.
Step 5.4 Record: Reachability is verified from userspace ioctl in the
syzkaller trace and reproducer: `openat("/dev/ptmx")`, `TIOCSETD` to
`N_HCI`, `HCIUARTSETPROTO` with fault injection, then `TIOCSTI`.
Step 5.5 Record: Similar HCI UART receive callbacks exist; some, like
`qca_recv` and `ll_recv`, still have `HCI_UART_REGISTERED` guards before
dereferencing private data. The candidate focuses on the four callbacks
identified in the accepted patch.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v6.19.14` and `v7.0.5`: the four callbacks
exist without the new NULL checks. These trees also have
`hci_uart_tty_receive()` accepting `HCI_UART_PROTO_INIT`. Checked
`v6.6`/`v6.12`: older receive gating differs, so the exact trigger is
less clearly present there.
Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `v7.0.5` checkout. Expected backport difficulty for similar
affected trees is clean or trivial.
Step 6.3 Record: No equivalent recv-callback NULL guard was found in
`v6.19.14` or `v7.0.5`. A related central cleanup exists upstream as
`68d39ea5e0ad`, but not in those checked stable tags.
## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Bluetooth HCI UART, a driver subsystem
under `drivers/bluetooth`. Criticality: important for systems using
UART-attached Bluetooth controllers; not universal core kernel code.
Step 7.2 Record: Bluetooth UART code is actively changing in this range,
with recent initialization-race and NULL-deref fixes in the same area.
## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with `N_HCI` / HCI UART
Bluetooth line discipline enabled, especially with H4/H5/ATH/BCSP
protocol paths.
Step 8.2 Record: Trigger verified by syzkaller requires HCI UART line
discipline setup, fault/error during protocol setup, then received data
through `TIOCSTI`. The reproducer uses fault injection and ioctl access;
unprivileged exploitability was not established.
Step 8.3 Record: Failure mode is kernel oops/general protection fault
from KASAN NULL dereference in `h4_recv`; severity HIGH to CRITICAL
because it crashes the kernel.
Step 8.4 Record: Benefit is high for affected stable trees because it
prevents a reproducible kernel crash. Risk is very low: 12 added lines,
no new feature, no locking changes, no API changes.
## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: syzbot report with
reproducer, KASAN NULL deref, syscall-triggered path, small surgical
patch, accepted by Bluetooth maintainer, applies cleanly to checked
stable tree. Evidence against: trigger appears tied to setup
failure/fault injection and may not affect older stable trees with
different HCI UART initialization flow. Unresolved: exact applicability
to every older LTS branch was not fully verified.
Step 9.2 Record: Stable rules checklist: obviously correct: yes; fixes
real bug: yes, syzbot crash; important issue: yes, kernel oops; small
and contained: yes, 12 insertions in four driver callbacks; no new
features/APIs: yes; applies to stable: yes for checked `v7.0.5`, likely
trivial for affected `v6.19.y`.
Step 9.3 Record: No exception category needed; this is a direct crash
fix, not a device ID/quirk/build/doc patch.
Step 9.4 Record: Decision is to backport to affected stable trees,
especially those containing the `HCI_UART_PROTO_INIT` receive path and
recent HCI UART initialization fixes. The benefit/risk ratio is strongly
favorable.
## Verification
- Phase 1: Parsed commit `902fe40bce7059722f7ffa1c378e577675cf1918` with
`git show`; verified syzbot and Closes tags.
- Phase 2: Verified diff stat: four files, 12 insertions, only NULL
guards in recv callbacks.
- Phase 3: Ran `git blame` on changed callback lines and inspected
related commits `0ffac654e95c`, `981b4fd2baf3`, `0c3cd7a0b862`, and
`68d39ea5e0ad`.
- Phase 4: Ran `b4 dig -c`, `-a`, and `-w`; fetched mirror thread and
syzkaller bug/reproducer.
- Phase 5: Verified call path with source reads and exact searches:
`tiocsti()` -> line discipline `receive_buf` ->
`hci_uart_tty_receive()` -> protocol `.recv`.
- Phase 6: Checked `v6.19.14`, `v7.0.5`, `v6.12`, and `v6.6` snippets;
verified patch applies to current `v7.0.5` with `git apply --check`.
- Phase 8: Verified failure mode from syzkaller crash log: KASAN NULL-
ptr-deref/general protection fault in `h4_recv`.
- UNVERIFIED: Exact applicability to every active older stable/LTS
branch; older branches with different HCI UART gating may not need
this patch.
**YES**
drivers/bluetooth/hci_ath.c | 3 +++
drivers/bluetooth/hci_bcsp.c | 3 +++
drivers/bluetooth/hci_h4.c | 3 +++
drivers/bluetooth/hci_h5.c | 3 +++
4 files changed, 12 insertions(+)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index fa679ad0acdfa..8201fa7f61e84 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -191,6 +191,9 @@ static int ath_recv(struct hci_uart *hu, const void *data, int count)
{
struct ath_struct *ath = hu->priv;
+ if (!ath)
+ return -ENODEV;
+
ath->rx_skb = h4_recv_buf(hu, ath->rx_skb, data, count,
ath_recv_pkts, ARRAY_SIZE(ath_recv_pkts));
if (IS_ERR(ath->rx_skb)) {
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index b386f91d8b46d..db56eead27ceb 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -585,6 +585,9 @@ static int bcsp_recv(struct hci_uart *hu, const void *data, int count)
if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
return -EUNATCH;
+ if (!bcsp)
+ return -ENODEV;
+
BT_DBG("hu %p count %d rx_state %d rx_count %ld",
hu, count, bcsp->rx_state, bcsp->rx_count);
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index a889a66a326f7..7673727074985 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -109,6 +109,9 @@ static int h4_recv(struct hci_uart *hu, const void *data, int count)
{
struct h4_struct *h4 = hu->priv;
+ if (!h4)
+ return -ENODEV;
+
h4->rx_skb = h4_recv_buf(hu, h4->rx_skb, data, count,
h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
if (IS_ERR(h4->rx_skb)) {
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index cfdf75dc28475..d353837182125 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -587,6 +587,9 @@ static int h5_recv(struct hci_uart *hu, const void *data, int count)
struct h5 *h5 = hu->priv;
const unsigned char *ptr = data;
+ if (!h5)
+ return -ENODEV;
+
BT_DBG("%s pending %zu count %d", hu->hdev->name, h5->rx_pending,
count);
--
2.53.0
^ permalink raw reply related
* RTL8922A (0bda:d922): BLE HID disconnects with supervision timeout (0x08) during active HFP/SCO call
From: Benjamin Mirko Blume @ 2026-05-20 11:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Max Chou
Hello,
This is a bug report for what looks like an SCO/eSCO versus BLE
airtime-scheduling problem on the Realtek RTL8922A USB combo controller:
a BLE-only HID device (mouse) is disconnected with link supervision
timeout whenever an HFP voice call (SCO) is active on the same
controller. The SCO audio link itself stays up; only the LE HID link
starves.
Adding Max Chou on Cc as the author of the RTL8922A btrtl support.
Environment
- Controller: Realtek RTL8922A combo, USB 0bda:d922, btusb
- Firmware: rtl_bt/rtl8922au_fw.bin, fw version 0x41c0c905
(linux-firmware 1:20260410), AOSP extensions v1.00
- Kernel: 6.18.32 x86_64. The same behaviour was present on the previous
non-LTS kernel 7.0.9-1, so it is not a kernel-version regression.
- BlueZ: 5.86
- Host: Lenovo Yoga 7 14AKP10, AMD Ryzen AI 7 350
- Peripherals:
- Logitech POP Mouse, BLE-only HID (HID-over-GATT), address
DB:5C:42:57:1E:1E
- Jabra Evolve2 65, HFP headset, SCO/eSCO on the same controller
Symptom
With both the BLE mouse and the Jabra headset connected to the RTL8922A,
the mouse works fine until an HFP voice call starts (mic active, so eSCO
with the Transparent/wideband codec). Within a few seconds the mouse
stops responding and is disconnected. With the headset used only for
A2DP playback (ACL) the mouse stays stable; the disconnects coincide
specifically with HFP/SCO.
Steps to reproduce
1. Pair and connect a BLE-only HID (mouse) to the RTL8922A.
2. Pair and connect an HFP headset to the same controller.
3. Start a voice call so the headset switches to HFP (eSCO active).
4. The BLE HID disconnects within seconds.
Evidence (btmon)
HCI Event: Disconnect Complete (0x05) Handle: 16
Status: Success (0x00)
Reason: Connection Timeout (0x08)
MGMT Event: Device Disconnected
LE Address: DB:5C:42:57:1E:1E (the mouse)
Reason: Connection timeout
During the disconnect window the bus is saturated with SCO data on the
headset handle (about one packet every 2 ms; 91714 SCO packets total in
the capture, 534 of them within the 2 s window in which the mouse was
silent). The last mouse ACL/ATT packet is at t=202.4 s; the Disconnect
Complete is at t=209.4 s, i.e. about 7 s with no serviced LE connection
events before the supervision timeout fires. SCO continues uninterrupted
before, during and after the LE timeout.
Interpretation and questions
The controller appears to keep the reserved (e)SCO slots while the LE
connection events are starved to the point of supervision timeout. On
other controllers (for example Intel) BLE HID survives an active HFP
call, so this looks like an RTL8922A firmware coexistence/scheduling
issue rather than a hard single-radio limitation.
- Is this a known limitation of the RTL8922A firmware?
- Is the SCO/LE arbitration firmware-tunable, or can the host side
mitigate it (for example via LE connection parameters)?
- Could this have regressed between linux-firmware versions? I am happy
to bisect linux-firmware if that would help.
Workaround
Moving the headset onto a separate USB dongle (off the RTL8922A) removes
all SCO load from the chip and the BLE HID stays connected.
I have a full btmon trace and can provide a short, payload-scrubbed
reproducer (the raw SCO payload contains call audio, so I would strip
it). Happy to test patches or gather more logs.
Thanks,
Benjamin Blume
^ permalink raw reply
* RE: Add Synaptics BCM4384 Bluetooth support
From: bluez.test.bot @ 2026-05-20 11:39 UTC (permalink / raw)
To: linux-bluetooth, kaihsin.chung
In-Reply-To: <20260520090131.3505676-2-kaihsin.chung@synaptics.com>
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml:23
error: Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Dmitry Baryshkov @ 2026-05-20 12:33 UTC (permalink / raw)
To: Loic Poulain
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <20260520-monza-wireless-v1-2-9f6942310653@oss.qualcomm.com>
On Wed, May 20, 2026 at 01:01:43PM +0200, Loic Poulain wrote:
> For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable
> is controlled by the W_DISABLE2# signal managed by the pcie-m2 power
> sequencer rather than a dedicated BT enable GPIO.
>
> When the serdev controller has an OF graph (indicating it is connected
> to an M.2 connector), acquire the 'uart' pwrseq target from the
> connector's power sequencer and use it to control BT power instead of
> the bt-enable GPIO.
>
> Also allocate bt_power unconditionally for all SOC types since the
> pwrseq path is independent of the SOC type switch.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/bluetooth/hci_qca.c | 33 +++++++++++++--------------------
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index b5439b9956cfb0497e6ba6ccd9ed61224d23a9dd..de5cba7b7f44e280a48dad5d670fa2758d3268d0 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1873,6 +1873,9 @@ static int qca_power_on(struct hci_dev *hdev)
> /* Controller needs time to bootup. */
> msleep(150);
> }
> +
> + if (qcadev->bt_power && qcadev->bt_power->pwrseq)
> + pwrseq_power_on(qcadev->bt_power->pwrseq);
> }
>
> clear_bit(QCA_BT_OFF, &qca->flags);
> @@ -2415,25 +2418,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> else
> qcadev->btsoc_type = QCA_ROME;
>
> - switch (qcadev->btsoc_type) {
> - case QCA_QCA6390:
> - case QCA_WCN3950:
> - case QCA_WCN3988:
> - case QCA_WCN3990:
> - case QCA_WCN3991:
> - case QCA_WCN3998:
> - case QCA_WCN6750:
> - case QCA_WCN6855:
> - case QCA_WCN7850:
> - qcadev->bt_power = devm_kzalloc(&serdev->dev,
> - sizeof(struct qca_power),
> - GFP_KERNEL);
> - if (!qcadev->bt_power)
> - return -ENOMEM;
> - break;
> - default:
> - break;
> - }
> + qcadev->bt_power = devm_kzalloc(&serdev->dev, sizeof(struct qca_power), GFP_KERNEL);
> + if (!qcadev->bt_power)
> + return -ENOMEM;
This builds bt_power for all devices even though it wasn't the case
beforehand. As such, you can drop all further `if (qcadev->bt_power)`
checks in the driver. But, you also need to check that this won't break
support for other (older) chips.
>
> switch (qcadev->btsoc_type) {
> case QCA_WCN3950:
> @@ -2543,7 +2530,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> return PTR_ERR(qcadev->bt_en);
> }
>
> - if (!qcadev->bt_en)
> + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
And this breaks support for pwrseq for non-M.2 BT devices. There is no
OF graph in such a case.
> + qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
> + if (IS_ERR(qcadev->bt_power->pwrseq))
> + return PTR_ERR(qcadev->bt_power->pwrseq);
> + }
> +
> + if (!qcadev->bt_en && !qcadev->bt_power->pwrseq)
> bt_en_available = false;
>
> qcadev->susclk = devm_clk_get_optional_enabled_with_rate(
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Dmitry Baryshkov @ 2026-05-20 12:34 UTC (permalink / raw)
To: Loic Poulain
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <20260520-monza-wireless-v1-3-9f6942310653@oss.qualcomm.com>
On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
> Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> Arduino VENTUNO Q board. The module is interfaced via LGA and is
> compatible with the M.2 Key E.
>
> Add wireless-lga-connector node using pcie-m2-e-connector binding,
> connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> the Bluetooth interface.
>
> Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> the pci-pwrctrl driver can acquire the power sequencer and enable
> the M.2 slot before PCIe enumeration.
>
> Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> (gpio56/gpio55) used by the power sequencer.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
> enable-active-high;
> startup-delay-us = <20000>;
> };
> +
> + wireless-lga-connector {
> + compatible = "pcie-m2-e-connector";
I think it was discussed that LGA can't be an actual M.2 E-key
connector.
> + vpcie3v3-supply = <&vdc_3v3>;
> + vpcie1v8-supply = <&vdc_1v8>;
> + w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
> + w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&nfa725b_default_state>;
> + pinctrl-names = "default";
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: Luiz Augusto von Dentz @ 2026-05-20 12:45 UTC (permalink / raw)
To: Shuai Zhang
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
In-Reply-To: <cf77b8bb-5427-4d0c-b212-51947704378a@oss.qualcomm.com>
Hi Shuai,
On Wed, May 20, 2026 at 2:26 AM Shuai Zhang
<shuai.zhang@oss.qualcomm.com> wrote:
>
> Hi Luiz
>
> On 4/29/2026 11:17 PM, Luiz Augusto von Dentz wrote:
> > Hi Shuai,
> >
> > On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
> > <shuai.zhang@oss.qualcomm.com> wrote:
> >> The Bluetooth host decides whether to download firmware by reading the
> >> controller firmware download completion flag and firmware version
> >> information.
> >>
> >> If a USB error occurs during the firmware download process (for example
> >> due to a USB disconnect), the download is aborted immediately. An
> >> incomplete firmware transfer does not cause the controller to set the
> >> download completion flag, but the firmware version information may be
> >> updated at an early stage of the download process.
> > Hold on, if the download has been aborted then the version should be
> > reverted, or rather just update once the firmware loading is complete,
> > so this indicates there is a bug somewhere that needs fixing, not
> > worked around.
> >
> >> In this case, after USB reconnection, the host attempts to re-download
> >> the firmware because the download completion flag is not set. However,
> >> since the controller reports the same firmware version as the target
> >> firmware, the download is skipped. This ultimately results in the
> >> firmware not being properly updated on the controller.
> >>
> >> This change removes the restriction that skips firmware download when
> >> the versions are equal. It covers scenarios where the USB connection
> >> can be disconnected at any time and ensures that firmware download can
> >> be retriggered after USB reconnection, allowing the Bluetooth firmware
> >> to be correctly and completely updated.
> >>
> >> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> >> ---
> >> Changes v2:
> >> - Update code comments and commit message to reflect the correct logic.
> >> - Align the commit title with upstream conventions.
> >> - Link v1
> >> https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
> >> ---
> >> drivers/bluetooth/btusb.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> >> index 572091e60..70abbabea 100644
> >> --- a/drivers/bluetooth/btusb.c
> >> +++ b/drivers/bluetooth/btusb.c
> >> @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
> >> "firmware rome 0x%x build 0x%x",
> >> rver_rom, rver_patch, ver_rom, ver_patch);
> >>
> >> - if (rver_rom != ver_rom || rver_patch <= ver_patch) {
> >> + /* Allow rampatch when the patch version equals the firmware version.
> >> + * A firmware download may be aborted by a transient USB error (e.g.
> >> + * disconnect) after the controller updates version info but before
> >> + * completion.
> >> + * Allowing equal versions enables re-flashing during recovery.
> >> + */
> >> + if (rver_rom != ver_rom || rver_patch < ver_patch) {
> > As I said above, this sounds more like a workaround. That said, I
> > wonder why it would print an error if the version matches, it sounds
> > to be that if the version matches it should just skip and consider it
> > has been loaded already in case the actual problem is fixed by setting
> > the new version only when loading has been completed.
> >
> >> bt_dev_err(hdev, "rampatch file version did not match with firmware");
> >> err = -EINVAL;
> >> goto done;
> >> --
> >> 2.34.1
>
> Just checking if there are any updates on this
I had the impression there would be more changes needed, if this not
the case than let me know, also perhaps we should consider adding a
Fixes tag since this might help users experiencing problem if they are
dual booting or somehow got the wrong firmware to be loaded.
>
> Thanks,
>
> Shuai
>
> >
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Greg KH @ 2026-05-20 12:47 UTC (permalink / raw)
To: August Wikerfors
Cc: Luiz Augusto von Dentz, Thorsten Leemhuis, stable@vger.kernel.org,
Sasha Levin, linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <e666c332-e2aa-4525-a208-a4a08742d2e0@augustwikerfors.se>
On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> >
> > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > Hi Greg,
> > > >
> > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > >
> > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > >
> > > > > > > > > > are available in the Git repository at:
> > > > > > > > > >
> > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > >
> > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > >
> > > > > > > > > > Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > >
> > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > that was merged yesterday.
> > > > > > > > >
> > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > -next].
> > > > > > > >
> > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > >
> > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > > > > of these:
> > > > > >
> > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > >
> > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > >
> > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > need:
> > > > > >
> > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > >
> > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > nightmare to track over time, ugh.
> > > >
> > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > for some reason, perhaps I'm running an outdated version or something
> > > > similar.
> > >
> > > Something went wrong if we ended up with a patch in the stable trees,
> > > yet this fix is referring to it as a different git sha. Don't know
> > > where the disconnect happend :(
> >
> > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > struct access")
> >
> > I don't have that in any of our tree either, this is actually
> > 634a4408c061 on all trees in the chain:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> >
> > Or actually that was the hash before it got rebased on bluetooth-next tree:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> >
> > But I didn't send the PR from that three so perhaps somebody else sent
> > it to stable with the wrong fixes tag?
> I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> FUNC_CTRL events" itself currently having different commit hashes in
> bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> struct access" as 634a4408c061 in the Fixes tag and was merged into net
> yesterday heading for 7.1-rc5. The latter still refers to it as
> 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> next-20260518 which was the latest at the time of Thorsten's message.
>
> Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> in a valid Fixes tag.
Ok, now done. Be careful of duplicate commits in different branches
that are marked for backporting with different ids. It can cause
massive confusion (i.e. don't be like the drm tree...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: remove extra copy in cmd array init
From: Luiz Augusto von Dentz @ 2026-05-20 12:55 UTC (permalink / raw)
To: Jiajia Liu
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260520021500.13504-1-liujiajia@kylinos.cn>
Hi Jiajia,
On Tue, May 19, 2026 at 10:15 PM Jiajia Liu <liujiajia@kylinos.cn> wrote:
>
> In btmtk_setup_firmware_79xx, the data length indicated by wmt_params.dlen
> in the cmd buffer is MTK_SEC_MAP_NEED_SEND_SIZE + 1. Except for the first
> byte, the remaining length is MTK_SEC_MAP_NEED_SEND_SIZE. memcpy copied one
> more byte to cmd + 1 than the remaining length. Align the length passed to
> memcpy to avoid exceeding current section map.
>
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/bluetooth/btmtk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index ea7a031000cd..53cba71cb07f 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -188,7 +188,7 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
> MTK_FW_ROM_PATCH_GD_SIZE +
> MTK_FW_ROM_PATCH_SEC_MAP_SIZE * i +
> MTK_SEC_MAP_COMMON_SIZE,
> - MTK_SEC_MAP_NEED_SEND_SIZE + 1);
> + MTK_SEC_MAP_NEED_SEND_SIZE);
>
> wmt_params.op = BTMTK_WMT_PATCH_DWNLD;
> wmt_params.status = &status;
> --
> 2.53.0
>
Have you tested this on the actual hardware? If not we need a Tested-by.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Luiz Augusto von Dentz @ 2026-05-20 13:11 UTC (permalink / raw)
To: Greg KH
Cc: August Wikerfors, Thorsten Leemhuis, stable@vger.kernel.org,
Sasha Levin, linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <2026052026-barber-espresso-1d9a@gregkh>
Hi Greg,
On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > Hi Greg,
> > >
> > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > >
> > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > > net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > >
> > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > >
> > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > >
> > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > >
> > > > > > > > > > > Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > >
> > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > that was merged yesterday.
> > > > > > > > > >
> > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > -next].
> > > > > > > > >
> > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > >
> > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > > > > > of these:
> > > > > > >
> > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > >
> > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > >
> > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > need:
> > > > > > >
> > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > >
> > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > nightmare to track over time, ugh.
> > > > >
> > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > similar.
> > > >
> > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > yet this fix is referring to it as a different git sha. Don't know
> > > > where the disconnect happend :(
> > >
> > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > struct access")
> > >
> > > I don't have that in any of our tree either, this is actually
> > > 634a4408c061 on all trees in the chain:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > >
> > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > >
> > > But I didn't send the PR from that three so perhaps somebody else sent
> > > it to stable with the wrong fixes tag?
> > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > FUNC_CTRL events" itself currently having different commit hashes in
> > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > yesterday heading for 7.1-rc5. The latter still refers to it as
> > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > next-20260518 which was the latest at the time of Thorsten's message.
> >
> > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > in a valid Fixes tag.
>
> Ok, now done. Be careful of duplicate commits in different branches
> that are marked for backporting with different ids. It can cause
> massive confusion (i.e. don't be like the drm tree...)
Noted. I guess I need to dig into how other trees do to avoid that.
The problem seem related to using 2 trees: bluetooth->net (fixes only,
rebased on each RC) versus bluetooth-next->net-next (development,
rebased once per release).
> thanks,
>
> greg k-h
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Greg KH @ 2026-05-20 13:15 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: August Wikerfors, Thorsten Leemhuis, stable@vger.kernel.org,
Sasha Levin, linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <CABBYNZJ4woc+unpYN6_dzMLtxhFVUd5+ccv2+EQbDMkYuXQ12A@mail.gmail.com>
On Wed, May 20, 2026 at 09:11:42AM -0400, Luiz Augusto von Dentz wrote:
> Hi Greg,
>
> On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > > Hi Greg,
> > > >
> > > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > > >
> > > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > > > net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > > >
> > > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > > >
> > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > > >
> > > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > > >
> > > > > > > > > > > > Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > > >
> > > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > > that was merged yesterday.
> > > > > > > > > > >
> > > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > > -next].
> > > > > > > > > >
> > > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > > >
> > > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > > > > > > of these:
> > > > > > > >
> > > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > > >
> > > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > > >
> > > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > > need:
> > > > > > > >
> > > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > > >
> > > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > > nightmare to track over time, ugh.
> > > > > >
> > > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > > similar.
> > > > >
> > > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > > yet this fix is referring to it as a different git sha. Don't know
> > > > > where the disconnect happend :(
> > > >
> > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > > struct access")
> > > >
> > > > I don't have that in any of our tree either, this is actually
> > > > 634a4408c061 on all trees in the chain:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > > >
> > > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > > >
> > > > But I didn't send the PR from that three so perhaps somebody else sent
> > > > it to stable with the wrong fixes tag?
> > > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > > FUNC_CTRL events" itself currently having different commit hashes in
> > > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > > yesterday heading for 7.1-rc5. The latter still refers to it as
> > > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > > next-20260518 which was the latest at the time of Thorsten's message.
> > >
> > > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > > in a valid Fixes tag.
> >
> > Ok, now done. Be careful of duplicate commits in different branches
> > that are marked for backporting with different ids. It can cause
> > massive confusion (i.e. don't be like the drm tree...)
>
> Noted. I guess I need to dig into how other trees do to avoid that.
> The problem seem related to using 2 trees: bluetooth->net (fixes only,
> rebased on each RC) versus bluetooth-next->net-next (development,
> rebased once per release).
Just never rebase any public tree please.
^ permalink raw reply
* [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-20 13:50 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-bluetooth, netdev, linux-kernel, stable
net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR
signaling packets up to the channel MTU and dispatches each command
without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer
within radio range can send a fixed-channel CID 0x0001 packet that is
larger than MTUsig and contains many L2CAP_ECHO_REQ commands before
pairing.
In a real-radio stock-kernel run, one 681-byte signaling
packet containing 168 zero-length ECHO_REQ commands made the target
transmit 168 ECHO_RSP frames over about 220 ms.
Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and
reject larger signaling packets before dispatching their commands. When
the over-MTUsig packet contains a request command, send one
L2CAP_COMMAND_REJECT_RSP with L2CAP_REJ_MTU_EXCEEDED and the first
request identifier; packets for which no valid request command is found
are dropped.
Cc: stable@vger.kernel.org
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
Assisted-by: Claude:claude-opus-4-7
Assisted-by: Codex:gpt-5-5-xhigh
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
I reproduced the stock behavior with a real-radio BR/EDR ACL link and a
harness that sends a single fixed-channel signaling packet containing
packed zero-length ECHO_REQ commands. The patched code builds for
net/bluetooth/l2cap_core.o on x86_64 defconfig. There are no in-tree
Bluetooth selftests that reference l2cap_sig_channel(), L2CAP_SIG_MTU,
or L2CAP_ECHO_REQ.
The unrestricted BR/EDR signaling parser and ECHO_REQ response path both
trace to the initial git import; no later introducing commit is
available for a Fixes tag.
Changes in v2:
- Replace the per-PDU echo-count cap with the MTUsig direction from
review.
- Reject the whole over-MTUsig signaling packet with one
L2CAP_REJ_MTU_EXCEEDED command reject.
- Add L2CAP_SIG_MTU and drop over-MTUsig packets when no valid request
command identifier is found.
v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 60 +++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 5172afee54943..e0a1f2293679a 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -33,6 +33,7 @@
/* L2CAP defaults */
#define L2CAP_DEFAULT_MTU 672
#define L2CAP_DEFAULT_MIN_MTU 48
+#define L2CAP_SIG_MTU 48 /* BR/EDR signaling MTU */
#define L2CAP_DEFAULT_FLUSH_TO 0xFFFF
#define L2CAP_EFS_DEFAULT_FLUSH_TO 0xFFFFFFFF
#define L2CAP_DEFAULT_TX_WINDOW 63
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 77dec104a9c36..5417e3cb0636d 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5626,6 +5626,55 @@ static inline void l2cap_sig_send_rej(struct l2cap_conn *conn, u16 ident)
l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
}
+static bool l2cap_sig_cmd_is_req(u8 code)
+{
+ switch (code) {
+ case L2CAP_CONN_REQ:
+ case L2CAP_CONF_REQ:
+ case L2CAP_DISCONN_REQ:
+ case L2CAP_ECHO_REQ:
+ case L2CAP_INFO_REQ:
+ case L2CAP_CONN_PARAM_UPDATE_REQ:
+ case L2CAP_LE_CONN_REQ:
+ case L2CAP_ECRED_CONN_REQ:
+ case L2CAP_ECRED_RECONF_REQ:
+ return true;
+ }
+
+ return false;
+}
+
+static u8 l2cap_sig_first_req_ident(const struct sk_buff *skb)
+{
+ const u8 *data = skb->data;
+ unsigned int len = skb->len;
+
+ while (len >= L2CAP_CMD_HDR_SIZE) {
+ const struct l2cap_cmd_hdr *cmd = (const void *)data;
+ u16 cmd_len = le16_to_cpu(cmd->len);
+
+ if (cmd->ident && l2cap_sig_cmd_is_req(cmd->code))
+ return cmd->ident;
+
+ if (cmd_len > len - L2CAP_CMD_HDR_SIZE)
+ break;
+
+ data += L2CAP_CMD_HDR_SIZE + cmd_len;
+ len -= L2CAP_CMD_HDR_SIZE + cmd_len;
+ }
+
+ return 0;
+}
+
+static inline void l2cap_sig_send_mtu_rej(struct l2cap_conn *conn, u8 ident)
+{
+ struct l2cap_cmd_rej_mtu rej;
+
+ rej.reason = cpu_to_le16(L2CAP_REJ_MTU_EXCEEDED);
+ rej.max_mtu = cpu_to_le16(L2CAP_SIG_MTU);
+ l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
+}
+
static inline void l2cap_sig_channel(struct l2cap_conn *conn,
struct sk_buff *skb)
{
@@ -5638,6 +5687,17 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
if (hcon->type != ACL_LINK)
goto drop;
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = l2cap_sig_first_req_ident(skb);
+
+ BT_DBG("signaling packet exceeds MTU");
+
+ if (ident)
+ l2cap_sig_send_mtu_rej(conn, ident);
+
+ goto drop;
+ }
+
while (skb->len >= L2CAP_CMD_HDR_SIZE) {
u16 len;
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] bluetooth 2026-05-14
From: Luiz Augusto von Dentz @ 2026-05-20 13:53 UTC (permalink / raw)
To: Greg KH
Cc: August Wikerfors, Thorsten Leemhuis, stable@vger.kernel.org,
Sasha Levin, linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <2026052047-silica-grub-0bb2@gregkh>
Hi Greg,
On Wed, May 20, 2026 at 9:14 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, May 20, 2026 at 09:11:42AM -0400, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> >
> > On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > > > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > > > > net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > > > >
> > > > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > > > >
> > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > > > >
> > > > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > > > >
> > > > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > > > that was merged yesterday.
> > > > > > > > > > > >
> > > > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > > > -next].
> > > > > > > > > > >
> > > > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > > > >
> > > > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > > > > > > > of these:
> > > > > > > > >
> > > > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > > > >
> > > > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > > > >
> > > > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > > > need:
> > > > > > > > >
> > > > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > > > >
> > > > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > > > nightmare to track over time, ugh.
> > > > > > >
> > > > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > > > similar.
> > > > > >
> > > > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > > > yet this fix is referring to it as a different git sha. Don't know
> > > > > > where the disconnect happend :(
> > > > >
> > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > > > struct access")
> > > > >
> > > > > I don't have that in any of our tree either, this is actually
> > > > > 634a4408c061 on all trees in the chain:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > > > >
> > > > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > > > >
> > > > > But I didn't send the PR from that three so perhaps somebody else sent
> > > > > it to stable with the wrong fixes tag?
> > > > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > > > FUNC_CTRL events" itself currently having different commit hashes in
> > > > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > > > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > > > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > > > yesterday heading for 7.1-rc5. The latter still refers to it as
> > > > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > > > next-20260518 which was the latest at the time of Thorsten's message.
> > > >
> > > > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > > > in a valid Fixes tag.
> > >
> > > Ok, now done. Be careful of duplicate commits in different branches
> > > that are marked for backporting with different ids. It can cause
> > > massive confusion (i.e. don't be like the drm tree...)
> >
> > Noted. I guess I need to dig into how other trees do to avoid that.
> > The problem seem related to using 2 trees: bluetooth->net (fixes only,
> > rebased on each RC) versus bluetooth-next->net-next (development,
> > rebased once per release).
>
> Just never rebase any public tree please.
I guess the alternative is to do merges, right? While I understand
this will not be changing the sha-ids I don't think it changes the
fact that fixes applied on the bluetooth-next cannot be merged into
bluetooth. Is there a way to retain the IDs across trees? The
alternative, I guess, would be to apply fixes to bluetooth tree and
then merge them back to bluetooth-next to preserve the IDs. This would
make the CI job slightly harder, as it would need to detect if a Fixes
tag exists; if so, it would probably need to go through the Bluetooth
tree first.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Luiz Augusto von Dentz @ 2026-05-20 14:00 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-bluetooth, netdev, linux-kernel,
stable
In-Reply-To: <20260520135034.1060859-1-michael.bommarito@gmail.com>
Hi Michael,
On Wed, May 20, 2026 at 9:50 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR
> signaling packets up to the channel MTU and dispatches each command
> without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer
> within radio range can send a fixed-channel CID 0x0001 packet that is
> larger than MTUsig and contains many L2CAP_ECHO_REQ commands before
> pairing.
>
> In a real-radio stock-kernel run, one 681-byte signaling
> packet containing 168 zero-length ECHO_REQ commands made the target
> transmit 168 ECHO_RSP frames over about 220 ms.
>
> Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and
> reject larger signaling packets before dispatching their commands. When
> the over-MTUsig packet contains a request command, send one
> L2CAP_COMMAND_REJECT_RSP with L2CAP_REJ_MTU_EXCEEDED and the first
> request identifier; packets for which no valid request command is found
> are dropped.
>
> Cc: stable@vger.kernel.org
> Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
> Assisted-by: Claude:claude-opus-4-7
> Assisted-by: Codex:gpt-5-5-xhigh
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> I reproduced the stock behavior with a real-radio BR/EDR ACL link and a
> harness that sends a single fixed-channel signaling packet containing
> packed zero-length ECHO_REQ commands. The patched code builds for
> net/bluetooth/l2cap_core.o on x86_64 defconfig. There are no in-tree
> Bluetooth selftests that reference l2cap_sig_channel(), L2CAP_SIG_MTU,
> or L2CAP_ECHO_REQ.
>
> The unrestricted BR/EDR signaling parser and ECHO_REQ response path both
> trace to the initial git import; no later introducing commit is
> available for a Fixes tag.
>
> Changes in v2:
> - Replace the per-PDU echo-count cap with the MTUsig direction from
> review.
> - Reject the whole over-MTUsig signaling packet with one
> L2CAP_REJ_MTU_EXCEEDED command reject.
> - Add L2CAP_SIG_MTU and drop over-MTUsig packets when no valid request
> command identifier is found.
>
> v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
> ---
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/l2cap_core.c | 60 +++++++++++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 5172afee54943..e0a1f2293679a 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -33,6 +33,7 @@
> /* L2CAP defaults */
> #define L2CAP_DEFAULT_MTU 672
> #define L2CAP_DEFAULT_MIN_MTU 48
> +#define L2CAP_SIG_MTU 48 /* BR/EDR signaling MTU */
> #define L2CAP_DEFAULT_FLUSH_TO 0xFFFF
> #define L2CAP_EFS_DEFAULT_FLUSH_TO 0xFFFFFFFF
> #define L2CAP_DEFAULT_TX_WINDOW 63
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 77dec104a9c36..5417e3cb0636d 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -5626,6 +5626,55 @@ static inline void l2cap_sig_send_rej(struct l2cap_conn *conn, u16 ident)
> l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
> }
>
> +static bool l2cap_sig_cmd_is_req(u8 code)
> +{
> + switch (code) {
> + case L2CAP_CONN_REQ:
> + case L2CAP_CONF_REQ:
> + case L2CAP_DISCONN_REQ:
> + case L2CAP_ECHO_REQ:
> + case L2CAP_INFO_REQ:
> + case L2CAP_CONN_PARAM_UPDATE_REQ:
> + case L2CAP_LE_CONN_REQ:
> + case L2CAP_ECRED_CONN_REQ:
> + case L2CAP_ECRED_RECONF_REQ:
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static u8 l2cap_sig_first_req_ident(const struct sk_buff *skb)
> +{
> + const u8 *data = skb->data;
> + unsigned int len = skb->len;
> +
> + while (len >= L2CAP_CMD_HDR_SIZE) {
> + const struct l2cap_cmd_hdr *cmd = (const void *)data;
> + u16 cmd_len = le16_to_cpu(cmd->len);
> +
> + if (cmd->ident && l2cap_sig_cmd_is_req(cmd->code))
> + return cmd->ident;
> +
> + if (cmd_len > len - L2CAP_CMD_HDR_SIZE)
> + break;
> +
> + data += L2CAP_CMD_HDR_SIZE + cmd_len;
> + len -= L2CAP_CMD_HDR_SIZE + cmd_len;
> + }
Weird, does the AI come up with this? The id is actually _not_
important because the error code will essentially indicate that the
entire packet was rejected. Therefore, it doesn't matter if the id is
for a request or a response, it still needs rejection if it exceeds
the MTU, so this seems overengineered.
> + return 0;
> +}
> +
> +static inline void l2cap_sig_send_mtu_rej(struct l2cap_conn *conn, u8 ident)
> +{
> + struct l2cap_cmd_rej_mtu rej;
> +
> + rej.reason = cpu_to_le16(L2CAP_REJ_MTU_EXCEEDED);
> + rej.max_mtu = cpu_to_le16(L2CAP_SIG_MTU);
> + l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
> +}
> +
> static inline void l2cap_sig_channel(struct l2cap_conn *conn,
> struct sk_buff *skb)
> {
> @@ -5638,6 +5687,17 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
> if (hcon->type != ACL_LINK)
> goto drop;
>
> + if (skb->len > L2CAP_SIG_MTU) {
> + u8 ident = l2cap_sig_first_req_ident(skb);
> +
> + BT_DBG("signaling packet exceeds MTU");
> +
> + if (ident)
> + l2cap_sig_send_mtu_rej(conn, ident);
> +
> + goto drop;
> + }
> +
> while (skb->len >= L2CAP_CMD_HDR_SIZE) {
> u16 len;
>
> --
> 2.53.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-20 14:12 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-bluetooth, netdev, linux-kernel,
stable
In-Reply-To: <CABBYNZLLw=VFfjaF_TXA=5ZgDt7rw=XgUULoc4JudMpUBf_BWg@mail.gmail.com>
On Wed, May 20, 2026 at 10:00 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Weird, does the AI come up with this? The id is actually _not_
> important because the error code will essentially indicate that the
> entire packet was rejected. Therefore, it doesn't matter if the id is
> for a request or a response, it still needs rejection if it exceeds
> the MTU, so this seems overengineered.
Yes, and I debated this with Claude, but it convinced me that the
lifted helpers were more idiomatic for the actual spec and bt system:
"The identifier shall match the first request command in the L2CAP
packet. If only responses are recognized, the packet shall be silently
discarded."
So if we ever lifted or refactored the code, it would be abundantly
clear/safe to reuse elsewhere.
There is also much shorter version that just peeks skb->data[1] and
exits early if not ident=0 if that's what you're going for.
Just let me know what version you prefer.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_core: Don't queue tx_work while draining workqueue
From: Heitor Alves de Siqueira @ 2026-05-20 14:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Heitor Alves de Siqueira
Cc: Hillf Danton, Marcel Holtmann, Gustavo Padovan, linux-bluetooth,
linux-kernel, kernel-dev, syzkaller-bugs,
syzbot+97721dd81f792e838ba0
In-Reply-To: <CABBYNZJdJ9GSeHjadoFJS4XRep2gx5R3+272evFgSkFKukg_bg@mail.gmail.com>
On Mon May 18, 2026 at 5:48 PM -03, Luiz Augusto von Dentz wrote:
> Hi Heitor,
>
> On Mon, May 18, 2026 at 11:21 AM Heitor Alves de Siqueira
> <halves@igalia.com> wrote:
>>
>> Hi Luiz,
>>
>> On Fri May 15, 2026 at 10:33 AM -03, Luiz Augusto von Dentz wrote:
>> > Hi Heitor,
>> >
>> > On Thu, May 14, 2026 at 10:54 AM Heitor Alves de Siqueira
>> > <halves@igalia.com> wrote:
>> >>
>> >> On Wed May 13, 2026 at 11:04 PM -03, Hillf Danton wrote:
>> >> > On Wed, 13 May 2026 15:55:23 -0300 Heitor Alves de Siqueira wrote:
>> >> >> Syzbot reported a warning when L2CAP calls queue_work() on the hdev
>> >> >> workqueue while it's being drained. This can happen during device reset or
>> >> >> close paths for hci_send_acl(), hci_send_sco() and hci_send_iso().
>> >> >>
>> >> >> The workqueue is drained in hci_dev_do_reset() and in hci_dev_close_sync():
>> >> >> - hci_dev_close_sync() clears the HCI_UP bit before draining
>> >> >> - hci_dev_do_reset() sets HCI_CMD_DRAIN_WORKQUEUE before draining
>> >> >>
>> >> >> Add these checks before queuing tx_work, and free the SKB if it's not
>> >> >> queued for transmission.
>> >> >>
>> >> >> Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue")
>> >> >> Reported-by: syzbot+97721dd81f792e838ba0@syzkaller.appspotmail.com
>> >> >> Closes: https://syzkaller.appspot.com/bug?extid=97721dd81f792e838ba0
>> >> >> Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com>
>> >> >> ---
>> >> >> net/bluetooth/hci_core.c | 18 ++++++++++++++++++
>> >> >> 1 file changed, 18 insertions(+)
>> >> >>
>> >> >> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
>> >> >> index c46c1236ebfa..5d5f8ad7d1a8 100644
>> >> >> --- a/net/bluetooth/hci_core.c
>> >> >> +++ b/net/bluetooth/hci_core.c
>> >> >> @@ -3278,6 +3278,12 @@ void hci_send_acl(struct hci_chan *chan, struct sk_buff *skb, __u16 flags)
>> >> >>
>> >> >> BT_DBG("%s chan %p flags 0x%4.4x", hdev->name, chan, flags);
>> >> >>
>> >> >> + if (!test_bit(HCI_UP, &hdev->flags) ||
>> >> >> + hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)) {
>> >> >> + kfree_skb(skb);
>> >> >> + return;
>> >> >> + }
>> >> >> +
>> >> >> hci_queue_acl(chan, &chan->data_q, skb, flags);
>> >> >>
>> >> >> queue_work(hdev->workqueue, &hdev->tx_work);
>> >> >>
>> >> > What you add is not enough, go and see how HCI_CMD_DRAIN_WORKQUEUE is
>> >> > checked in hci_cmd_work(), and in hci_dev_do_reset() for why.
>> >>
>> >> I see, I missed the RCU guards for the device flags. Sorry about that,
>> >> I'll add them to v2.
>> >> Thanks for the catch!
>> >
>> > Actually this whole thing might be because we try to clean the
>> > workqueue without actually closing the hdev, so I suspect that if we
>> > just remove all the code from hci_dev_do_reset with
>> > hci_dev_do_close+hci_dev_do_open, it might work better and align with
>> > how things work over the MGMT interface:
>> >
>> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
>> > index c46c1236ebfa..6782bbc9b6a7 100644
>> > --- a/net/bluetooth/hci_core.c
>> > +++ b/net/bluetooth/hci_core.c
>> > @@ -539,47 +539,13 @@ static int hci_dev_do_reset(struct hci_dev *hdev)
>> >
>> > hci_req_sync_lock(hdev);
>> >
>> > - /* Drop queues */
>> > - skb_queue_purge(&hdev->rx_q);
>> > - skb_queue_purge(&hdev->cmd_q);
>> > -
>> > - /* Cancel these to avoid queueing non-chained pending work */
>> > - hci_dev_set_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
>> > - /* Wait for
>> > - *
>> > - * if (!hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE))
>> > - * queue_delayed_work(&hdev->{cmd,ncmd}_timer)
>> > - *
>> > - * inside RCU section to see the flag or complete scheduling.
>> > - */
>> > - synchronize_rcu();
>> > - /* Explicitly cancel works in case scheduled after setting the flag. */
>> > - cancel_delayed_work(&hdev->cmd_timer);
>> > - cancel_delayed_work(&hdev->ncmd_timer);
>> > -
>> > - /* Avoid potential lockdep warnings from the *_flush() calls by
>> > - * ensuring the workqueue is empty up front.
>> > - */
>> > - drain_workqueue(hdev->workqueue);
>> > -
>> > - hci_dev_lock(hdev);
>> > - hci_inquiry_cache_flush(hdev);
>> > - hci_conn_hash_flush(hdev);
>> > - hci_dev_unlock(hdev);
>> > -
>> > - if (hdev->flush)
>> > - hdev->flush(hdev);
>> > -
>> > - hci_dev_clear_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
>> > -
>> > - atomic_set(&hdev->cmd_cnt, 1);
>> > - hdev->acl_cnt = 0;
>> > - hdev->sco_cnt = 0;
>> > - hdev->le_cnt = 0;
>> > - hdev->iso_cnt = 0;
>> > + ret = hci_dev_close_sync(hdev);
>> > + if (ret)
>> > + goto done;
>> >
>> > - ret = hci_reset_sync(hdev);
>> > + ret = hci_dev_open_sync(hdev);
>> >
>> > +done:
>> > hci_req_sync_unlock(hdev);
>> > return ret;
>> > }
>> >
>> > Seem to work here and as a side effect we get notified over the MGMT
>> > when a user uses hciconfig hci0 reset:
>> >
>> > # tools/hciconfig hci0 reset
>> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
>> > bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac0
>> > bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
>> > bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
>> > bluetoothd[34]: src/adapter.c:cancel_passive_scanning()
>> > bluetoothd[34]: src/adapter.c:adapter_stop() adapter /org/bluez/hci0
>> > has been disabled
>> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0008
>> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
>> > bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac1
>> > bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
>> > bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
>> > bluetoothd[34]: src/adapter.c:adapter_start() adapter /org/bluez/hci0
>> > has been enabled
>> > bluetoothd[34]: src/adapter.c:trigger_passive_scanning()
>> > bluetoothd[34]: [signal] org.freedesktop.DBus.Properties.PropertiesChanged
>>
>> Thank you for the review, and for the suggestion! There seems to be a
>> number of similar syzbot reports for the hdev workqueue, so maybe the
>> close+open approach is a simpler solution indeed. I've originally
>> considered implementing a wrapper/helper for workqueue submission in
>> hci_core.c, but if we can eliminate the race condition altogether that'd
>> be even better.
>>
>> My only concern is that there seem to be slight differences between
>> what hci_dev_do_reset() does now and what we'd get with
>> hci_dev_close_sync()+hci_dev_open_sync() (e.g. we wouldn't use
>> HCI_CMD_DRAIN_WORKQUEUE anymore). Would this alternative approach be
>> suitable for the stable kernels? And if not, do you think the checks
>> from v1 would be appropriate, in that case?
>
> I think, the HCI_Reset is a heavy hammer because it's a global reset.
> Getting all the pieces to cooperate has been causing all sort of
> issues, and in any case I think what hci_dev_do_reset does is simply
> wrong or outdated; for instance it doesn't seem to affect LE, such as
> cancelling scanning or advertising. This is likely because interfaces
> like MGMT don't use it and require a power cycle to reset.
ACK, that makes sense. Please disregard this patch, I'll send a
follow-up with the reset changes and any missing bits from the current
async reset path.
Thank you for the pointers, Luiz!
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Loic Poulain @ 2026-05-20 14:29 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <jetl37zsfcs5kl4b7iarbngrdu4ebp7ag2cvpqvkku6tbl6r5n@qozh6n5fq7f3>
On Wed, May 20, 2026 at 2:34 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
> > Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> > Arduino VENTUNO Q board. The module is interfaced via LGA and is
> > compatible with the M.2 Key E.
> >
> > Add wireless-lga-connector node using pcie-m2-e-connector binding,
> > connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> > the Bluetooth interface.
> >
> > Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> > the pci-pwrctrl driver can acquire the power sequencer and enable
> > the M.2 slot before PCIe enumeration.
> >
> > Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> > (gpio56/gpio55) used by the power sequencer.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
> > 1 file changed, 65 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
> > --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
> > enable-active-high;
> > startup-delay-us = <20000>;
> > };
> > +
> > + wireless-lga-connector {
> > + compatible = "pcie-m2-e-connector";
>
> I think it was discussed that LGA can't be an actual M.2 E-key
> connector.
I am not sure I followed this discussion. Do you mean that I should
introduce a dedicated LGA/vendor-compatible string in the compatible
list of the pcie-m2-e-connector binding, or that LGA-based designs
should not be described using the pcie-m2-e-connector binding (graph
representation)?
>
> > + vpcie3v3-supply = <&vdc_3v3>;
> > + vpcie1v8-supply = <&vdc_1v8>;
> > + w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
> > + w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
> > + pinctrl-0 = <&nfa725b_default_state>;
> > + pinctrl-names = "default";
> > +
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Dmitry Baryshkov @ 2026-05-20 14:36 UTC (permalink / raw)
To: Loic Poulain
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <CAFEp6-0A=LrU44pu2rfUqXW9k9peSu=b2qq_FVs4WZUj-g4pDA@mail.gmail.com>
On Wed, May 20, 2026 at 04:29:40PM +0200, Loic Poulain wrote:
> On Wed, May 20, 2026 at 2:34 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
> > > Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> > > Arduino VENTUNO Q board. The module is interfaced via LGA and is
> > > compatible with the M.2 Key E.
> > >
> > > Add wireless-lga-connector node using pcie-m2-e-connector binding,
> > > connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> > > the Bluetooth interface.
> > >
> > > Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> > > the pci-pwrctrl driver can acquire the power sequencer and enable
> > > the M.2 slot before PCIe enumeration.
> > >
> > > Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> > > (gpio56/gpio55) used by the power sequencer.
> > >
> > > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
> > > 1 file changed, 65 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
> > > --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
> > > enable-active-high;
> > > startup-delay-us = <20000>;
> > > };
> > > +
> > > + wireless-lga-connector {
> > > + compatible = "pcie-m2-e-connector";
> >
> > I think it was discussed that LGA can't be an actual M.2 E-key
> > connector.
>
> I am not sure I followed this discussion. Do you mean that I should
> introduce a dedicated LGA/vendor-compatible string in the compatible
> list of the pcie-m2-e-connector binding, or that LGA-based designs
> should not be described using the pcie-m2-e-connector binding (graph
> representation)?
I think, it should be a separate, vendor-specific compat (maybe using
m2-e as a fallback).
>
>
> >
> > > + vpcie3v3-supply = <&vdc_3v3>;
> > > + vpcie1v8-supply = <&vdc_1v8>;
> > > + w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
> > > + w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
> > > + pinctrl-0 = <&nfa725b_default_state>;
> > > + pinctrl-names = "default";
> > > +
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Loic Poulain @ 2026-05-20 14:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <n6kl7y47hztf7tgtdxhakpekwkxlleggv4sbzpsd2ncpill6ii@bdk5esjubv4t>
On Wed, May 20, 2026 at 4:36 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Wed, May 20, 2026 at 04:29:40PM +0200, Loic Poulain wrote:
> > On Wed, May 20, 2026 at 2:34 PM Dmitry Baryshkov
> > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > >
> > > On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
> > > > Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> > > > Arduino VENTUNO Q board. The module is interfaced via LGA and is
> > > > compatible with the M.2 Key E.
> > > >
> > > > Add wireless-lga-connector node using pcie-m2-e-connector binding,
> > > > connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> > > > the Bluetooth interface.
> > > >
> > > > Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> > > > the pci-pwrctrl driver can acquire the power sequencer and enable
> > > > the M.2 slot before PCIe enumeration.
> > > >
> > > > Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> > > > (gpio56/gpio55) used by the power sequencer.
> > > >
> > > > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
> > > > 1 file changed, 65 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > > index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
> > > > --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > > +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> > > > @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
> > > > enable-active-high;
> > > > startup-delay-us = <20000>;
> > > > };
> > > > +
> > > > + wireless-lga-connector {
> > > > + compatible = "pcie-m2-e-connector";
> > >
> > > I think it was discussed that LGA can't be an actual M.2 E-key
> > > connector.
> >
> > I am not sure I followed this discussion. Do you mean that I should
> > introduce a dedicated LGA/vendor-compatible string in the compatible
> > list of the pcie-m2-e-connector binding, or that LGA-based designs
> > should not be described using the pcie-m2-e-connector binding (graph
> > representation)?
>
> I think, it should be a separate, vendor-specific compat (maybe using
> m2-e as a fallback).
ok, understood.
>
> >
> >
> > >
> > > > + vpcie3v3-supply = <&vdc_3v3>;
> > > > + vpcie1v8-supply = <&vdc_1v8>;
> > > > + w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
> > > > + w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
> > > > + pinctrl-0 = <&nfa725b_default_state>;
> > > > + pinctrl-names = "default";
> > > > +
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* RE: [v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: bluez.test.bot @ 2026-05-20 14:48 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260520135034.1060859-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2400 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=1098049
---Test result---
Test Summary:
CheckPatch FAIL 0.96 seconds
GitLint FAIL 0.31 seconds
SubjectPrefix PASS 0.12 seconds
BuildKernel PASS 27.08 seconds
CheckAllWarning PASS 30.16 seconds
CheckSparse PASS 28.23 seconds
BuildKernel32 PASS 25.90 seconds
TestRunnerSetup PASS 577.67 seconds
TestRunner_l2cap-tester PASS 378.48 seconds
IncrementalBuild PASS 25.39 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?
total: 0 errors, 1 warnings, 0 checks, 79 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.
/github/workspace/src/patch/14584036.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:
[v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
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
23: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
47: B1 Line exceeds max length (82>80): "v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
https://github.com/bluez/bluetooth-next/pull/220
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Luiz Augusto von Dentz @ 2026-05-20 15:18 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-bluetooth, netdev, linux-kernel,
stable
In-Reply-To: <CAJJ9bXw9r2XHYMkmjbJ9XAiGEG3VEWK6bjKHbHgwJqnOBzTu9w@mail.gmail.com>
Hi Michael,
On Wed, May 20, 2026 at 10:13 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Wed, May 20, 2026 at 10:00 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > Weird, does the AI come up with this? The id is actually _not_
> > important because the error code will essentially indicate that the
> > entire packet was rejected. Therefore, it doesn't matter if the id is
> > for a request or a response, it still needs rejection if it exceeds
> > the MTU, so this seems overengineered.
>
> Yes, and I debated this with Claude, but it convinced me that the
> lifted helpers were more idiomatic for the actual spec and bt system:
> "The identifier shall match the first request command in the L2CAP
> packet. If only responses are recognized, the packet shall be silently
> discarded."
This coming from the spec is priceless because silently discarding the
packets means the remote stack won't know the responses were
discarded, causing the stacks to go out of sync. We also shouldn't
process packets beyond the allowed MTU. Therefore, I strongly disagree
with the spec requiring an identifier on the reject, as this implies
that even if a custom MTU is set, the packet must still be processed
if it exceeds that MTU to find the first request command within it.
> So if we ever lifted or refactored the code, it would be abundantly
> clear/safe to reuse elsewhere.
>
> There is also much shorter version that just peeks skb->data[1] and
> exits early if not ident=0 if that's what you're going for.
>
> Just let me know what version you prefer.
>
> Thanks,
> Mike
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-20 15:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-bluetooth, netdev, linux-kernel,
stable
In-Reply-To: <CABBYNZ+q1c+3Su_3_ib=zbVMD35tgwMGjdV3OwM5a3GXOq1aRg@mail.gmail.com>
On Wed, May 20, 2026 at 11:19 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> This coming from the spec is priceless because silently discarding the
> packets means the remote stack won't know the responses were
> discarded, causing the stacks to go out of sync. We also shouldn't
> process packets beyond the allowed MTU. Therefore, I strongly disagree
> with the spec requiring an identifier on the reject, as this implies
> that even if a custom MTU is set, the packet must still be processed
> if it exceeds that MTU to find the first request command within it.
Should I keep a verbose comment string about this rationale in the
next version? This seems like something that might trigger questions
in the future if there are issues between Linux <-> noisy/buggy
stacks.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Luiz Augusto von Dentz @ 2026-05-20 16:15 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-bluetooth, netdev, linux-kernel,
stable
In-Reply-To: <CAJJ9bXykBr1FQP8++kUL7ceXKp2u92+zySCqVEQqCm_+KLXj0Q@mail.gmail.com>
Hi Michael,
On Wed, May 20, 2026 at 11:23 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Wed, May 20, 2026 at 11:19 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > This coming from the spec is priceless because silently discarding the
> > packets means the remote stack won't know the responses were
> > discarded, causing the stacks to go out of sync. We also shouldn't
> > process packets beyond the allowed MTU. Therefore, I strongly disagree
> > with the spec requiring an identifier on the reject, as this implies
> > that even if a custom MTU is set, the packet must still be processed
> > if it exceeds that MTU to find the first request command within it.
>
> Should I keep a verbose comment string about this rationale in the
> next version? This seems like something that might trigger questions
> in the future if there are issues between Linux <-> noisy/buggy
> stacks.
Yep, be as verbose as possible, and quote the specification whenever necessary.
> Thanks,
> Mike
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v5 0/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Siwei Zhang @ 2026-05-20 16:20 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz; +Cc: linux-bluetooth, Siwei Zhang
Compared to v2, addresses comments on https://sashiko.dev/#/patchset/20260415204842.2363950-1-oss%40fourdim.xyz .
Compared to v3, rebase against bluetooth-next.
Compared to v4, allocate the channel outside the function and pass it in as an argument to avoid the use-after-free.
Siwei Zhang (1):
Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
include/net/bluetooth/l2cap.h | 8 +++--
net/bluetooth/6lowpan.c | 14 ++++-----
net/bluetooth/l2cap_core.c | 58 ++++++++++++++++++++++++++++-------
net/bluetooth/l2cap_sock.c | 48 +++++++++++++++++------------
net/bluetooth/smp.c | 13 +++-----
5 files changed, 91 insertions(+), 50 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v5 1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Siwei Zhang @ 2026-05-20 16:20 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz; +Cc: linux-bluetooth, Siwei Zhang
In-Reply-To: <20260520162030.2842543-1-oss@fourdim.xyz>
l2cap_sock_new_connection_cb() accesses l2cap_pi(sk)->chan after
release_sock(parent). Once the parent lock is released, the child
socket sk can be freed by another task.
Allocate the channel outside the func to prevent this.
Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
Cc: stable@kernel.org
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
include/net/bluetooth/l2cap.h | 8 +++--
net/bluetooth/6lowpan.c | 14 ++++-----
net/bluetooth/l2cap_core.c | 58 ++++++++++++++++++++++++++++-------
net/bluetooth/l2cap_sock.c | 48 +++++++++++++++++------------
net/bluetooth/smp.c | 13 +++-----
5 files changed, 91 insertions(+), 50 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 5172afee5494..f7a11e6431f0 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -619,7 +619,8 @@ struct l2cap_chan {
struct l2cap_ops {
char *name;
- struct l2cap_chan *(*new_connection) (struct l2cap_chan *chan);
+ int (*new_connection)(struct l2cap_chan *chan,
+ struct l2cap_chan *new_chan);
int (*recv) (struct l2cap_chan * chan,
struct sk_buff *skb);
void (*teardown) (struct l2cap_chan *chan, int err);
@@ -883,9 +884,10 @@ static inline __u16 __next_seq(struct l2cap_chan *chan, __u16 seq)
return (seq + 1) % (chan->tx_win_max + 1);
}
-static inline struct l2cap_chan *l2cap_chan_no_new_connection(struct l2cap_chan *chan)
+static inline int l2cap_chan_no_new_connection(struct l2cap_chan *chan,
+ struct l2cap_chan *new_chan)
{
- return NULL;
+ return -EOPNOTSUPP;
}
static inline int l2cap_chan_no_recv(struct l2cap_chan *chan, struct sk_buff *skb)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 23a229ab6a33..286c0b45055b 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -743,19 +743,19 @@ static inline void chan_ready_cb(struct l2cap_chan *chan)
ifup(dev->netdev);
}
-static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
+static inline int chan_new_conn_cb(struct l2cap_chan *pchan,
+ struct l2cap_chan *chan)
{
- struct l2cap_chan *chan;
-
- chan = chan_create();
- if (!chan)
- return NULL;
+ l2cap_chan_set_defaults(chan);
+ chan->chan_type = L2CAP_CHAN_CONN_ORIENTED;
+ chan->mode = L2CAP_MODE_LE_FLOWCTL;
+ chan->imtu = 1280;
chan->ops = pchan->ops;
BT_DBG("chan %p pchan %p", chan, pchan);
- return chan;
+ return 0;
}
static void unregister_dev(struct lowpan_btle_dev *dev)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index fdccd62ccca8..505f32034971 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4051,10 +4051,16 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
goto response;
}
- chan = pchan->ops->new_connection(pchan);
+ chan = l2cap_chan_create();
if (!chan)
goto response;
+ if (pchan->ops->new_connection(pchan, chan) < 0) {
+ l2cap_chan_put(chan);
+ chan = NULL;
+ goto response;
+ }
+
/* For certain devices (ex: HID mouse), support for authentication,
* pairing and bonding is optional. For such devices, inorder to avoid
* the ACL alive for too long after L2CAP disconnection, reset the ACL
@@ -4132,6 +4138,10 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
chan->num_conf_req++;
}
+ /* Drop our local ref; __l2cap_chan_add() pinned chan via the conn list. */
+ if (chan)
+ l2cap_chan_put(chan);
+
l2cap_chan_unlock(pchan);
l2cap_chan_put(pchan);
}
@@ -4881,6 +4891,7 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
struct l2cap_le_conn_rsp rsp;
struct l2cap_chan *chan, *pchan;
u16 dcid, scid, credits, mtu, mps;
+ u16 rsp_mtu, rsp_mps;
__le16 psm;
u8 result;
@@ -4893,6 +4904,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
psm = req->psm;
dcid = 0;
credits = 0;
+ rsp_mtu = 0;
+ rsp_mps = 0;
if (mtu < 23 || mps < 23)
return -EPROTO;
@@ -4953,12 +4966,19 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
goto response_unlock;
}
- chan = pchan->ops->new_connection(pchan);
+ chan = l2cap_chan_create();
if (!chan) {
result = L2CAP_CR_LE_NO_MEM;
goto response_unlock;
}
+ if (pchan->ops->new_connection(pchan, chan) < 0) {
+ l2cap_chan_put(chan);
+ chan = NULL;
+ result = L2CAP_CR_LE_NO_MEM;
+ goto response_unlock;
+ }
+
bacpy(&chan->src, &conn->hcon->src);
bacpy(&chan->dst, &conn->hcon->dst);
chan->src_type = bdaddr_src_type(conn->hcon);
@@ -4974,6 +4994,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
dcid = chan->scid;
credits = chan->rx_credits;
+ rsp_mtu = chan->imtu;
+ rsp_mps = chan->mps;
__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
@@ -4993,6 +5015,9 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
result = L2CAP_CR_LE_SUCCESS;
}
+ /* Drop our local ref; __l2cap_chan_add() pinned chan via the conn list. */
+ l2cap_chan_put(chan);
+
response_unlock:
l2cap_chan_unlock(pchan);
l2cap_chan_put(pchan);
@@ -5001,13 +5026,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
return 0;
response:
- if (chan) {
- rsp.mtu = cpu_to_le16(chan->imtu);
- rsp.mps = cpu_to_le16(chan->mps);
- } else {
- rsp.mtu = 0;
- rsp.mps = 0;
- }
+ rsp.mtu = cpu_to_le16(rsp_mtu);
+ rsp.mps = cpu_to_le16(rsp_mps);
rsp.dcid = cpu_to_le16(dcid);
rsp.credits = cpu_to_le16(credits);
@@ -5177,12 +5197,18 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
continue;
}
- chan = pchan->ops->new_connection(pchan);
+ chan = l2cap_chan_create();
if (!chan) {
result = L2CAP_CR_LE_NO_MEM;
continue;
}
+ if (pchan->ops->new_connection(pchan, chan) < 0) {
+ l2cap_chan_put(chan);
+ result = L2CAP_CR_LE_NO_MEM;
+ continue;
+ }
+
bacpy(&chan->src, &conn->hcon->src);
bacpy(&chan->dst, &conn->hcon->dst);
chan->src_type = bdaddr_src_type(conn->hcon);
@@ -5217,6 +5243,9 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
} else {
l2cap_chan_ready(chan);
}
+
+ /* Drop our local ref; __l2cap_chan_add() pinned chan via the conn list. */
+ l2cap_chan_put(chan);
}
unlock:
@@ -7399,7 +7428,11 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
goto next;
l2cap_chan_lock(pchan);
- chan = pchan->ops->new_connection(pchan);
+ chan = l2cap_chan_create();
+ if (chan && pchan->ops->new_connection(pchan, chan) < 0) {
+ l2cap_chan_put(chan);
+ chan = NULL;
+ }
if (chan) {
bacpy(&chan->src, &hcon->src);
bacpy(&chan->dst, &hcon->dst);
@@ -7407,6 +7440,9 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
chan->dst_type = dst_type;
__l2cap_chan_add(conn, chan);
+
+ /* Drop our local ref; __l2cap_chan_add() pinned chan via the conn list. */
+ l2cap_chan_put(chan);
}
l2cap_chan_unlock(pchan);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index dede550d6031..598f24c8f704 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -46,7 +46,8 @@ static struct bt_sock_list l2cap_sk_list = {
static const struct proto_ops l2cap_sock_ops;
static void l2cap_sock_init(struct sock *sk, struct sock *parent);
static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
- int proto, gfp_t prio, int kern);
+ int proto, gfp_t prio, int kern,
+ struct l2cap_chan *chan);
static void l2cap_sock_cleanup_listen(struct sock *parent);
bool l2cap_is_socket(struct socket *sock)
@@ -1507,12 +1508,13 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
}
}
-static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
+static int l2cap_sock_new_connection_cb(struct l2cap_chan *chan,
+ struct l2cap_chan *new_chan)
{
struct sock *sk, *parent = chan->data;
if (!parent)
- return NULL;
+ return -EINVAL;
lock_sock(parent);
@@ -1520,15 +1522,15 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
if (sk_acceptq_is_full(parent)) {
BT_DBG("backlog full %d", parent->sk_ack_backlog);
release_sock(parent);
- return NULL;
+ return -ENOBUFS;
}
sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP,
- GFP_ATOMIC, 0);
+ GFP_ATOMIC, 0, new_chan);
if (!sk) {
release_sock(parent);
- return NULL;
- }
+ return -ENOMEM;
+ }
bt_sock_reclassify_lock(sk, BTPROTO_L2CAP);
@@ -1538,7 +1540,7 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
release_sock(parent);
- return l2cap_pi(sk)->chan;
+ return 0;
}
static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
@@ -1939,10 +1941,10 @@ static struct proto l2cap_proto = {
};
static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
- int proto, gfp_t prio, int kern)
+ int proto, gfp_t prio, int kern,
+ struct l2cap_chan *chan)
{
struct sock *sk;
- struct l2cap_chan *chan;
sk = bt_sock_alloc(net, sock, &l2cap_proto, proto, prio, kern);
if (!sk)
@@ -1953,14 +1955,11 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
INIT_LIST_HEAD(&l2cap_pi(sk)->rx_busy);
- chan = l2cap_chan_create();
- if (!chan) {
- sk_free(sk);
- if (sock)
- sock->sk = NULL;
- return NULL;
- }
-
+ /* The sock owns two refs on chan, matching the puts in
+ * l2cap_sock_kill() and l2cap_sock_destruct(). The caller keeps
+ * its own ref independent of these.
+ */
+ l2cap_chan_hold(chan);
l2cap_chan_hold(chan);
l2cap_pi(sk)->chan = chan;
@@ -1972,6 +1971,7 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
int kern)
{
struct sock *sk;
+ struct l2cap_chan *chan;
BT_DBG("sock %p", sock);
@@ -1986,10 +1986,18 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
sock->ops = &l2cap_sock_ops;
- sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern);
- if (!sk)
+ chan = l2cap_chan_create();
+ if (!chan)
return -ENOMEM;
+ sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern, chan);
+ if (!sk) {
+ l2cap_chan_put(chan);
+ return -ENOMEM;
+ }
+ /* Sock has taken its own refs on chan; drop the chan_create() ref. */
+ l2cap_chan_put(chan);
+
l2cap_sock_init(sk, NULL);
bt_sock_link(&l2cap_sk_list, sk);
return 0;
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 1739c1989dbd..25cb5dc580bf 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -3204,16 +3204,11 @@ static const struct l2cap_ops smp_chan_ops = {
.get_sndtimeo = l2cap_chan_no_get_sndtimeo,
};
-static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
+static inline int smp_new_conn_cb(struct l2cap_chan *pchan,
+ struct l2cap_chan *chan)
{
- struct l2cap_chan *chan;
-
BT_DBG("pchan %p", pchan);
- chan = l2cap_chan_create();
- if (!chan)
- return NULL;
-
chan->chan_type = pchan->chan_type;
chan->ops = &smp_chan_ops;
chan->scid = pchan->scid;
@@ -3229,9 +3224,9 @@ static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
*/
atomic_set(&chan->nesting, L2CAP_NESTING_SMP);
- BT_DBG("created chan %p", chan);
+ BT_DBG("initialised chan %p", chan);
- return chan;
+ return 0;
}
static const struct l2cap_ops smp_root_chan_ops = {
--
2.54.0
^ permalink raw reply related
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