* [bluez/action-ci] 0be099: all: Fix "exit" typos
From: hadess @ 2026-05-21 18:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/main
Home: https://github.com/bluez/action-ci
Commit: 0be0998f89cd216d1b4d3461e583db3840832774
https://github.com/bluez/action-ci/commit/0be0998f89cd216d1b4d3461e583db3840832774
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M entrypoint.sh
M sync_repo.sh
Log Message:
-----------
all: Fix "exit" typos
Commit: 3dfee91519ae21d4828ed91b26a91f951cbef3f0
https://github.com/bluez/action-ci/commit/3dfee91519ae21d4828ed91b26a91f951cbef3f0
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M entrypoint.sh
M sync_repo.sh
Log Message:
-----------
*.sh: Fix double quote errors from shellcheck
Fix all double-quote warnings from shellcheck:
Double quote to prevent globbing and word splitting.
And add quotes in the "echo" calls that show how those commands are run.
Compare: https://github.com/bluez/action-ci/compare/9b6d3efc8435...3dfee91519ae
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/action-ci/settings/notifications
^ permalink raw reply
* [bluez/action-ci] 9b6d3e: gitlint: ignore lines with URLs and enable regex-s...
From: Luiz Augusto von Dentz @ 2026-05-21 18:40 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/main
Home: https://github.com/bluez/action-ci
Commit: 9b6d3efc843524b8fb96a978c10f2de7185a7bf0
https://github.com/bluez/action-ci/commit/9b6d3efc843524b8fb96a978c10f2de7185a7bf0
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M gitlint
Log Message:
-----------
gitlint: ignore lines with URLs and enable regex-style-search
Lines containing URLs (Link: tags, lore.kernel.org references) cannot
be reasonably wrapped to 80 chars. Ignore them along with Fixes: tags.
Also set regex-style-search=true to suppress the deprecation warning
about switching from match to search semantics.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/action-ci/settings/notifications
^ permalink raw reply
* [bluez/action-ci] f2343f: ci: use HEAD^2 in verify scripts to skip GitHub me...
From: Luiz Augusto von Dentz @ 2026-05-21 18:35 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/main
Home: https://github.com/bluez/action-ci
Commit: f2343f58b696e2ba1f3703957034fad22623744f
https://github.com/bluez/action-ci/commit/f2343f58b696e2ba1f3703957034fad22623744f
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M ci/verifyfixes.py
M ci/verifysignedoff.py
Log Message:
-----------
ci: use HEAD^2 in verify scripts to skip GitHub merge commit
GitHub Actions checks out refs/pull/N/merge which is a merge commit
authored by the bot. In shallow clones --no-merges may not filter it
correctly. Use origin/master..HEAD^2 to target only the actual PR
commits.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/action-ci/settings/notifications
^ permalink raw reply
* RE: [v4] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: bluez.test.bot @ 2026-05-21 17:23 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260521144518.1361335-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3443 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=1098859
---Test result---
Test Summary:
CheckPatch FAIL 0.80 seconds
VerifyFixes PASS 0.48 seconds
VerifySignedoff FAIL 0.22 seconds
GitLint FAIL 0.21 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 27.63 seconds
CheckAllWarning PASS 29.12 seconds
CheckSparse PASS 27.57 seconds
BuildKernel32 PASS 25.63 seconds
TestRunnerSetup PASS 578.13 seconds
TestRunner_l2cap-tester PASS 61.59 seconds
IncrementalBuild PASS 24.97 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v4] 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, 65 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/14587556.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: VerifySignedoff - FAIL
Desc: Verify Signed-off-by chain
Output:
Commit e9a1f367f155 ("Merge fec51f9217e4a020fb088da178104f4d925554fb into 133f77de6bca4b8873bcf67e3469bf1b28771a68")
author Signed-off-by missing
committer Signed-off-by missing
author email: 61600790+BluezTestBot@users.noreply.github.com
committer email: noreply@github.com
Errors in tree with Signed-off-by, please fix!
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v4] 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
37: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
38: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
39: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com"
77: B1 Line exceeds max length (82>80): "v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
78: B1 Line exceeds max length (82>80): "v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
79: B1 Line exceeds max length (82>80): "v3: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com"
https://github.com/bluez/bluetooth-next/pull/231
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Thorsten Leemhuis @ 2026-05-21 17:13 UTC (permalink / raw)
To: Greg KH, Linus Torvalds
Cc: Luiz Augusto von Dentz, August Wikerfors, stable@vger.kernel.org,
Sasha Levin, linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list
In-Reply-To: <CAHk-=whwq2_iaf7pTuzVXEcJmng_exwae_bKtgSDdm4BQivGHg@mail.gmail.com>
On 5/20/26 21:32, Linus Torvalds wrote:
> On Wed, 20 May 2026 at 08:53, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>>> Just never rebase any public tree please.
>> I guess the alternative is to do merges, right?
> No. Back-merges are bad too, unless they have a really damn solid
> reason for them, and some "keep up with other peoples work" is not
> that.
>
> The primary model should be that you care about your own work, and
> make sure that that is as stable as possible. Do *NOT* try to chase
> other people's work. Not with merges, not with rebases. [...]
> [...]
> Sometimes you have to rebase because of a mistake. Sometimes you need
> to do back-merges. But you should damn well have *reasons* for both
> that aren't "that's just how we work".
Speaking of mistakes, one happens occasionally that you afaics did not
cover here. And it's one where I'd be interested in your opinion (and
maybe Greg's from the stable perspective, too):
How to deal with cases where one fix was merged to a public -next branch
for merging in the next cycle (and thus was mixed up with many
non-fixes) but then turns out should be mainlined this cycle?
I notice such situations a few times per month. I just had exactly that
case for a patch fixing a 7.0 regression. And the answer I got was round
about "sorry, the fix is already in our -next tree, we thus can't merge
it this cycle"[1]. And that seemed wrong to me, which is why I argued
for cherry-picking in that case, but it seems I was not convincing.
And yes, I understand that cherry-picking causes pain (especially for
the stable team) and thus is best avoided -- but mistakes like that will
always happen, so it might be best to know what to do in that case.
> [...]
Ciao, Thorsten
[1] it's for a regression introduced in the 7.0 cycle:
https://lore.kernel.org/all/29a93dc3d9d24b3a809310694ffc5d34@realtek.com/
-- the tree in question afaics is not even in -next, as I can't see the
fix there
^ permalink raw reply
* [bluez/action-ci] c1b86b: ci: add verify_fixes and verify_signedoff checks f...
From: Luiz Augusto von Dentz @ 2026-05-21 15:48 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/main
Home: https://github.com/bluez/action-ci
Commit: c1b86bca7cacc936bea82b3ca8b2ee4b4fcb6e74
https://github.com/bluez/action-ci/commit/c1b86bca7cacc936bea82b3ca8b2ee4b4fcb6e74
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Dockerfile
M ci.py
M ci/__init__.py
A ci/verifyfixes.py
A ci/verifysignedoff.py
A scripts/verify_fixes.sh
A scripts/verify_signedoff.sh
Log Message:
-----------
ci: add verify_fixes and verify_signedoff checks for kernel patches
Add scripts from gregkh/gregkh-linux adapted for GitHub Actions:
- verify_fixes.sh: validates Fixes: tag format, SHA existence, subject
match, and ancestry (removed external Linus tree dependency)
- verify_signedoff.sh: validates author/committer Signed-off-by presence
Both run against origin/master..HEAD after checkpatch in the kernel CI
pipeline and report results as warnings to patchwork.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/action-ci/settings/notifications
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Siwei Zhang; +Cc: marcel, luiz.dentz, linux-bluetooth
In-Reply-To: <20260521023055.3272712-1-oss@fourdim.xyz>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 20 May 2026 22:30:36 -0400 you wrote:
> __set_chan_timer() takes a l2cap_chan reference via l2cap_chan_hold()
> before scheduling the delayed work. The normal path in
> l2cap_chan_timeout() drops this reference with l2cap_chan_put() at the
> end, but the early return when chan->conn is NULL skips the put,
> leaking the reference.
>
> Add the missing l2cap_chan_put() before the early return.
>
> [...]
Here is the summary with links:
- Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
https://git.kernel.org/bluetooth/bluetooth-next/c/628669434306
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: remove extra copy in cmd array init
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Jiajia Liu
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260520021500.13504-1-liujiajia@kylinos.cn>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 20 May 2026 10:15:00 +0800 you 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>
>
> [...]
Here is the summary with links:
- Bluetooth: btmtk: remove extra copy in cmd array init
https://git.kernel.org/bluetooth/bluetooth-next/c/b3e1ce138148
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Pavitra Jha
Cc: linux-bluetooth, luiz.dentz, marcel, johan.hedberg, linux-kernel,
stable, yang.li
In-Reply-To: <20260521080414.44460-1-jhapavitra98@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 21 May 2026 04:04:14 -0400 you wrote:
> hci_le_big_terminate() allocates iso_list_data via kzalloc_obj but
> returns 0 without freeing it when neither pa_sync_term nor big_sync_term
> flags are set after evaluating the PA and BIG sync connection state.
>
> This early-return path was introduced when hci_le_big_terminate() was
> refactored to take struct hci_conn instead of raw u8 parameters, adding
> PA/BIG flag evaluation logic. The existing kfree() on hci_cmd_sync_queue
> failure does not cover this path.
>
> [...]
Here is the summary with links:
- Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()
https://git.kernel.org/bluetooth/bluetooth-next/c/6dbf781d0885
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Siwei Zhang; +Cc: linux-bluetooth, luiz.dentz, safa.karakus, stable
In-Reply-To: <20260521021249.3258069-1-oss@fourdim.xyz>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 20 May 2026 22:12:20 -0400 you wrote:
> l2cap_chan_close() removes the channel from conn->chan_l, which
> must be done under conn->lock. cleanup_listen() runs under the
> parent sk_lock, so acquiring conn->lock would invert the
> established conn->lock -> chan->lock -> sk_lock order.
>
> Instead of calling l2cap_chan_close() directly, schedule
> l2cap_chan_timeout with delay 0 to close the channel
> asynchronously. The timeout handler already acquires conn->lock
> and chan->lock in the correct order.
>
> [...]
Here is the summary with links:
- [v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
https://git.kernel.org/bluetooth/bluetooth-next/c/75780ca4c6a8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, linux-kernel, marcel, luiz.dentz, johan.hedberg,
stable
In-Reply-To: <20260520225643.35683-1-meatuni001@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 20 May 2026 18:56:43 -0400 you wrote:
> hidp_input_report() reads keyboard and mouse payload data from an skb
> without first verifying that skb->len contains enough data.
>
> hidp_recv_intr_frame() pulls the 1-byte HIDP header before dispatching
> to hidp_input_report(). If a paired device sends a truncated packet,
> the handler reads beyond the valid skb data, resulting in an
> out-of-bounds read of skb data. The OOB bytes may be interpreted as
> phantom key presses or spurious mouse movement.
>
> [...]
Here is the summary with links:
- [v3] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
https://git.kernel.org/bluetooth/bluetooth-next/c/6522ecbcd122
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: btusb: Allow firmware re-download when version matches
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Shuai Zhang
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu,
shuai.zhang, stable
In-Reply-To: <20260521052547.2862803-1-shuaz@qti.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 21 May 2026 13:25:47 +0800 you wrote:
> From: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>
> 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.
>
> [...]
Here is the summary with links:
- [v3] Bluetooth: btusb: Allow firmware re-download when version matches
https://git.kernel.org/bluetooth/bluetooth-next/c/3c2c428f25e2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: patchwork-bot+bluetooth @ 2026-05-21 15:30 UTC (permalink / raw)
To: Shuai Zhang
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
In-Reply-To: <20260429121207.1306526-1-shuai.zhang@oss.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 29 Apr 2026 20:12:07 +0800 you 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.
>
> [...]
Here is the summary with links:
- [v2] Bluetooth: btusb: Allow firmware re-download when version matches
https://git.kernel.org/bluetooth/bluetooth-next/c/3c2c428f25e2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v4] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-21 14:45 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260521000555.3712030-1-michael.bommarito@gmail.com>
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.
Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can
force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling
packet containing packed ECHO_REQ commands.
Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and
reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP
carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.
The Bluetooth Core spec wording for MTUExceeded says the reject
identifier shall match the first request command in the packet, and
that packets containing only responses shall be silently discarded.
Linux intentionally deviates from that prescription: silently
discarding desynchronizes the peer because the remote stack never
learns its responses were dropped, and locating the first request
command requires walking command headers past MTUsig, i.e. processing
bytes from a packet we have already decided is too large to process.
We therefore always emit one reject and use the identifier from the
first command header, a single fixed-offset byte read.
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.
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
Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
Link: https://lore.kernel.org/r/20260521000555.3712030-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, and confirmed on a patched kernel
that the same packet now produces one L2CAP_REJ_MTU_EXCEEDED command
reject and zero ECHO_RSP frames. The patched code builds for
net/bluetooth/l2cap_core.o on x86_64 defconfig with W=1. There are no
in-tree Bluetooth selftests that reference l2cap_sig_channel(),
L2CAP_SIG_MTU, or L2CAP_ECHO_REQ.
Changes in v4:
- Drop the unreachable short-header fallback before reading the first
command identifier; any packet over L2CAP_SIG_MTU is large enough to
carry an L2CAP command header.
- Print both skb->len and L2CAP_SIG_MTU in the over-MTUsig debug trace.
Changes in v3:
- Drop l2cap_sig_cmd_is_req() and l2cap_sig_first_req_ident(); the
reject is now unconditional and uses only the first command
header's identifier byte at a fixed offset. Per Luiz, the spec's
"match the first request command identifier" rule would require
parsing past MTUsig, and the spec's "silently discard if only
responses" rule desynchronizes the peer.
- Replace the v2 walk with a verbose comment quoting the relevant
Bluetooth Core section and documenting why Linux deviates.
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
v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
v3: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 46 +++++++++++++++++++++++++++++++++++
2 files changed, 47 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 7701528f11677..17ee28a2ee78e 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5618,6 +5618,15 @@ 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 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)
{
@@ -5630,6 +5639,43 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
if (hcon->type != ACL_LINK)
goto drop;
+ /*
+ * Bluetooth Core v5.4, Vol 3, Part A, Section 4: the BR/EDR
+ * signaling channel has a fixed signaling MTU (MTUsig) whose
+ * minimum and default is 48 octets. Section 4.1 says that on
+ * an MTUExceeded command reject the identifier "shall match
+ * the first request command in the L2CAP packet" and that
+ * packets containing only response commands "shall be
+ * silently discarded".
+ *
+ * Linux intentionally deviates from that prescription:
+ *
+ * 1. Silently discarding desynchronizes the peer. The
+ * remote stack never learns its responses were dropped,
+ * so any state machine waiting on a paired response
+ * stalls until its own timer fires.
+ *
+ * 2. Locating "the first request command" requires walking
+ * command headers past MTUsig, i.e. processing bytes
+ * from a packet we have already decided is too large to
+ * process.
+ *
+ * Reject every over-MTUsig signaling packet with one
+ * L2CAP_REJ_MTU_EXCEEDED command reject. The reject's
+ * reason field is what tells the peer that the whole packet
+ * was discarded; the identifier value is informational, so
+ * we use the identifier from the first command header, a
+ * single fixed-offset byte read.
+ */
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = skb->data[1];
+
+ BT_DBG("signaling packet exceeds MTU: %u > %u",
+ skb->len, L2CAP_SIG_MTU);
+ 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
* [bluez/bluez]
From: BluezTestBot @ 2026-05-21 14:39 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096181
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-21 14:32 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1097304
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-21 14:32 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1098419
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-21 14:32 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1098468
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-21 14:31 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1098658
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 247044: tester.config: add missing CRYPTO_AES
From: michael kong @ 2026-05-21 14:30 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 2470448ed9d7ddff2347215a91b28de3a4565b0c
https://github.com/bluez/bluez/commit/2470448ed9d7ddff2347215a91b28de3a4565b0c
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M doc/ci.config
M doc/test-runner.rst
M doc/tester.config
Log Message:
-----------
tester.config: add missing CRYPTO_AES
Kernel commit 4a1507625b0 ("Bluetooth: SMP: Use AES-CMAC library
API") removed CRYPTO_AES from the default Bluetooth kernel config.
This causes Bluetooth testbots to fail silently with "Not Run" status:
Basic Framework - Success - init
Read Index List callback
Status: 0x00
Bluetooth: hci0: Opcode 0x0c03 failed: -110
Bluetooth: hci0: Opcode 0x0c03 failed: -110
hciemu: Failed to open vhci
Failed to setup HCI emulation
Basic Framework - Success - pre setup failed
Basic Framework - Success - done
...
SCO CVSD Listen Send - Success Not Run
Total: 30, Passed: 0 (0.0%), Failed: 0, Not Run: 30
Fix by explicitly requiring CRYPTO_AES.
Commit: 0e55974d713b699166fe56f11974e8520596076b
https://github.com/bluez/bluez/commit/0e55974d713b699166fe56f11974e8520596076b
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/bap.c
M client/btpclient/btpclient.c
M client/btpclient/btpclient.h
M client/btpclient/core.c
M client/btpclient/gap.c
M client/btpclient/gatt.c
Log Message:
-----------
client/btpclient: refactor read-commands bitmap building
Add add_supported_command() and use it across all btp_*_read_commands
handlers.
This replaces fixed-size bitmask assembly with a dynamically growing
command bitmap based on opcode index, avoiding shift-width issues with
higher opcodes.
This will allow to add opcodes like GAP_SET_EXTENDED_ADVERTISING
(0x21).
Refactor core, gap, gatt and bap read-commands paths to build response
bitmaps through the shared helper and preserve existing error handling
for allocation failures.
Assisted-by: GPT:GPT-5.3-Codex
Commit: 9074d38c5fed33cd6b611b9663f600c4f68bb741
https://github.com/bluez/bluez/commit/9074d38c5fed33cd6b611b9663f600c4f68bb741
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
Log Message:
-----------
client/btpclient: Replace advertising defines by shared ones
The advertisement types are already defined in src/shared/ad.h
Commit: 588a0267d8fabf146a0f35c85f30e06394fb526f
https://github.com/bluez/bluez/commit/588a0267d8fabf146a0f35c85f30e06394fb526f
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
M src/shared/btp.h
Log Message:
-----------
client/btpclient: Add BTP_OP_GAP_SET_EXTENDED_ADVERTISING support
This set LEAdvertisement1's SecondaryChannel property to "2M" to
force Extended advertisement type.
Commit: 29fb17c909a0998b09aaee1dc0fb6163bd2619cb
https://github.com/bluez/bluez/commit/29fb17c909a0998b09aaee1dc0fb6163bd2619cb
Author: michael_kong <kx960506@163.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M src/shared/bap.c
Log Message:
-----------
shared/bap: Fix unused value in qos
In bt_bap_parse_base, PresentationDelay is parsed but not written to QoS.
Commit: fd25b4b1e5968a68ab9e9ef626c25d9cb4c24241
https://github.com/bluez/bluez/commit/fd25b4b1e5968a68ab9e9ef626c25d9cb4c24241
Author: michael_kong <kx960506@163.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M profiles/audio/transport.c
Log Message:
-----------
transport: Add support for obtaining PresentationDelay in broadcast QoS
Commit: d167d3409e94440da7fb021d7d6d4601b65a83b5
https://github.com/bluez/bluez/commit/d167d3409e94440da7fb021d7d6d4601b65a83b5
Author: michael_kong <kx960506@163.com>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M doc/btmon-le-audio.rst
Log Message:
-----------
doc: Fix Data Path direction in btmon-le-audio.rst
The Data Path direction 0x01 should be Output (Controller to Host).
Compare: https://github.com/bluez/bluez/compare/757cd98f4186...d167d3409e94
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* RE: [v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: bluez.test.bot @ 2026-05-21 14:26 UTC (permalink / raw)
To: linux-bluetooth, oss
In-Reply-To: <20260521021249.3258069-1-oss@fourdim.xyz>
[-- Attachment #1: Type: text/plain, Size: 1880 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=1098389
---Test result---
Test Summary:
CheckPatch PASS 0.66 seconds
GitLint FAIL 0.28 seconds
SubjectPrefix PASS 0.10 seconds
BuildKernel PASS 25.36 seconds
CheckAllWarning PASS 28.35 seconds
CheckSparse PASS 26.31 seconds
BuildKernel32 PASS 24.49 seconds
TestRunnerSetup PASS 525.81 seconds
TestRunner_l2cap-tester FAIL 59.03 seconds
IncrementalBuild PASS 24.10 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
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
21: B1 Line exceeds max length (109>80): "Cc: <stable@vger.kernel.org> # 0b58004: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()"
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Total: 96, Passed: 95 (99.0%), Failed: 1, Not Run: 0
Failed Test Cases
L2CAP BR/EDR Server - Set PHY 1M Failed 0.261 seconds
https://github.com/bluez/bluetooth-next/pull/230
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH BlueZ 1/2] shared/bap: Fix unused value in qos
From: patchwork-bot+bluetooth @ 2026-05-21 13:40 UTC (permalink / raw)
To: michael_kong; +Cc: linux-bluetooth
In-Reply-To: <20260521032815.1845-1-kx960506@163.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 21 May 2026 11:28:14 +0800 you wrote:
> In bt_bap_parse_base, PresentationDelay is parsed but not written to QoS.
> ---
> src/shared/bap.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Here is the summary with links:
- [BlueZ,1/2] shared/bap: Fix unused value in qos
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=29fb17c909a0
- [BlueZ,2/2] transport: Add support for obtaining PresentationDelay in broadcast QoS
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=fd25b4b1e596
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ] doc: Fix Data Path direction in btmin-le-audio.rst
From: patchwork-bot+bluetooth @ 2026-05-21 13:40 UTC (permalink / raw)
To: michael_kong; +Cc: linux-bluetooth
In-Reply-To: <20260521060919.2124-1-kx960506@163.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 21 May 2026 14:09:19 +0800 you wrote:
> The Data Path direction 0x01 should be Output (Controller to Host).
> ---
> doc/btmon-le-audio.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Here is the summary with links:
- [BlueZ] doc: Fix Data Path direction in btmin-le-audio.rst
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=d167d3409e94
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ] tester.config: add missing CRYPTO_AES
From: patchwork-bot+bluetooth @ 2026-05-21 13:30 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <478a4d370bc0b20b98223507166dfd580ae8477d.1779051031.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 17 May 2026 23:51:30 +0300 you wrote:
> Kernel commit 4a1507625b0 ("Bluetooth: SMP: Use AES-CMAC library
> API") removed CRYPTO_AES from the default Bluetooth kernel config.
>
> This causes Bluetooth testbots to fail silently with "Not Run" status:
>
> Basic Framework - Success - init
> Read Index List callback
> Status: 0x00
> Bluetooth: hci0: Opcode 0x0c03 failed: -110
> Bluetooth: hci0: Opcode 0x0c03 failed: -110
> hciemu: Failed to open vhci
> Failed to setup HCI emulation
> Basic Framework - Success - pre setup failed
> Basic Framework - Success - done
> ...
> SCO CVSD Listen Send - Success Not Run
> Total: 30, Passed: 0 (0.0%), Failed: 0, Not Run: 30
>
> [...]
Here is the summary with links:
- [BlueZ] tester.config: add missing CRYPTO_AES
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=2470448ed9d7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ 0/3] client/btpclient: Add GAP extended advertising support
From: patchwork-bot+bluetooth @ 2026-05-21 13:30 UTC (permalink / raw)
To: =?utf-8?b?RnLDqWTDqXJpYyBEYW5pcyA8ZnJlZGVyaWMuZGFuaXNAY29sbGFib3JhLmNvbT4=?=
Cc: linux-bluetooth
In-Reply-To: <20260519105519.226648-1-frederic.danis@collabora.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 19 May 2026 12:55:16 +0200 you wrote:
> The BTP_OP_GAP_SET_EXTENDED_ADVERTISING command is used by at least the
> BAP/USR/DISC/BV-01-C test.
>
> Since this opcode is defined as 0x21 (33), it does not fit into the
> current fixed-size command bitmap. This series refactors the way
> btpclient reports supported auto-PTS commands so it can grow the bitmap
> dynamically as needed.
>
> [...]
Here is the summary with links:
- [BlueZ,1/3] client/btpclient: refactor read-commands bitmap building
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=0e55974d713b
- [BlueZ,2/3] client/btpclient: Replace advertising defines by shared ones
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=9074d38c5fed
- [BlueZ,3/3] client/btpclient: Add BTP_OP_GAP_SET_EXTENDED_ADVERTISING support
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=588a0267d8fa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox