* Re: [PATCH v2] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
From: Luiz Augusto von Dentz @ 2026-05-20 22:03 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, linux-kernel, marcel, johan.hedberg, stable
In-Reply-To: <20260520214133.27746-1-meatuni001@gmail.com>
Hi Muhammad,
On Wed, May 20, 2026 at 5:41 PM Muhammad Bilal <meatuni001@gmail.com> 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.
>
> Add a check that skb->len is non-zero before the type switch, and
> per-report-type minimum length checks before accessing the payload.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
> ---
> net/bluetooth/hidp/core.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 976f91eeb..03838a6ff 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -179,12 +179,22 @@ static void hidp_input_report(struct hidp_session *session, struct sk_buff *skb)
> {
> struct input_dev *dev = session->input;
> unsigned char *keys = session->keys;
> - unsigned char *udata = skb->data + 1;
> - signed char *sdata = skb->data + 1;
> - int i, size = skb->len - 1;
> + unsigned char *udata;
> + signed char *sdata;
> + int i, size;
> +
> + if (!skb->len)
> + return;
> +
> + udata = skb->data + 1;
> + sdata = skb->data + 1;
> + size = skb->len - 1;
If you use skb_pull_data, you won't need to use pointer arithmetic, or
store the actual size.
>
> switch (skb->data[0]) {
> case 0x01: /* Keyboard report */
> + if (size < 8)
> + break;
> +
> for (i = 0; i < 8; i++)
> input_report_key(dev, hidp_keycode[i + 224], (udata[0] >> i) & 1);
>
> @@ -213,6 +223,9 @@ static void hidp_input_report(struct hidp_session *session, struct sk_buff *skb)
> break;
>
> case 0x02: /* Mouse report */
> + if (size < 3)
> + break;
> +
> input_report_key(dev, BTN_LEFT, sdata[0] & 0x01);
> input_report_key(dev, BTN_RIGHT, sdata[0] & 0x02);
> input_report_key(dev, BTN_MIDDLE, sdata[0] & 0x04);
> --
> 2.54.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v3] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
From: Muhammad Bilal @ 2026-05-20 22:56 UTC (permalink / raw)
To: linux-bluetooth
Cc: linux-kernel, Marcel Holtmann, Luiz Augusto von Dentz,
Johan Hedberg, stable, Muhammad Bilal
In-Reply-To: <CABBYNZ+Oc=LU6d8_xK9_a9yk-TFyaE=0KsNvAwKbNZVs1EJpWg@mail.gmail.com>
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.
Replace the open-coded length tracking and pointer arithmetic with
skb_pull_data() calls. skb_pull_data() returns NULL if the requested
bytes are not present, eliminating the need for a manual size variable
and the separate skb->len guard.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
v3:
- Replace manual length checks and pointer arithmetic with
skb_pull_data() per Luiz's review
v2:
- Add Cc: stable@vger.kernel.org per Greg KH's note
---
net/bluetooth/hidp/core.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 976f91eeb..70344bd32 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -179,12 +179,21 @@ static void hidp_input_report(struct hidp_session *session, struct sk_buff *skb)
{
struct input_dev *dev = session->input;
unsigned char *keys = session->keys;
- unsigned char *udata = skb->data + 1;
- signed char *sdata = skb->data + 1;
- int i, size = skb->len - 1;
+ unsigned char *udata;
+ signed char *sdata;
+ u8 *hdr;
+ int i;
+
+ hdr = skb_pull_data(skb, 1);
+ if (!hdr)
+ return;
- switch (skb->data[0]) {
+ switch (*hdr) {
case 0x01: /* Keyboard report */
+ udata = skb_pull_data(skb, 8);
+ if (!udata)
+ break;
+
for (i = 0; i < 8; i++)
input_report_key(dev, hidp_keycode[i + 224], (udata[0] >> i) & 1);
@@ -213,6 +222,10 @@ static void hidp_input_report(struct hidp_session *session, struct sk_buff *skb)
break;
case 0x02: /* Mouse report */
+ sdata = skb_pull_data(skb, 3);
+ if (!sdata)
+ break;
+
input_report_key(dev, BTN_LEFT, sdata[0] & 0x01);
input_report_key(dev, BTN_RIGHT, sdata[0] & 0x02);
input_report_key(dev, BTN_MIDDLE, sdata[0] & 0x04);
@@ -222,7 +235,7 @@ static void hidp_input_report(struct hidp_session *session, struct sk_buff *skb)
input_report_rel(dev, REL_X, sdata[1]);
input_report_rel(dev, REL_Y, sdata[2]);
- if (size > 3)
+ if (skb->len > 0)
input_report_rel(dev, REL_WHEEL, sdata[3]);
break;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-21 0:05 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
In-Reply-To: <20260520135034.1060859-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), falling back
to zero when the packet is too short to carry a header at all.
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
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 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
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 47 +++++++++++++++++++++++++++++++++++
2 files changed, 48 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..0b1e062057695 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,44 @@ 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) or zero when the packet is
+ * too short to carry even one header.
+ */
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = (skb->len >= L2CAP_CMD_HDR_SIZE) ?
+ skb->data[1] : 0;
+
+ BT_DBG("signaling packet exceeds 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
* [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-21 0:13 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.
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), falling back
to zero when the packet is too short to carry a header at all.
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
Assisted-by: Claude:claude-opus-4-7
Assisted-by: Codex:gpt-5-5-xhigh
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Resending as top level message per netdev guidance.
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 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
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 47 +++++++++++++++++++++++++++++++++++
2 files changed, 48 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..0b1e062057695 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,44 @@ 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) or zero when the packet is
+ * too short to carry even one header.
+ */
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = (skb->len >= L2CAP_CMD_HDR_SIZE) ?
+ skb->data[1] : 0;
+
+ BT_DBG("signaling packet exceeds 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
* RE: [v2] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
From: bluez.test.bot @ 2026-05-21 0:16 UTC (permalink / raw)
To: linux-bluetooth, meatuni001
In-Reply-To: <20260520214133.27746-1-meatuni001@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2191 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=1098310
---Test result---
Test Summary:
CheckPatch FAIL 0.65 seconds
GitLint PASS 0.27 seconds
SubjectPrefix PASS 0.10 seconds
BuildKernel PASS 25.15 seconds
CheckAllWarning PASS 28.02 seconds
CheckSparse PASS 27.24 seconds
BuildKernel32 PASS 26.55 seconds
TestRunnerSetup PASS 541.52 seconds
TestRunner_l2cap-tester PASS 378.34 seconds
TestRunner_iso-tester PASS 597.47 seconds
TestRunner_bnep-tester PASS 18.47 seconds
TestRunner_mgmt-tester PASS 2023.12 seconds
TestRunner_rfcomm-tester PASS 63.46 seconds
TestRunner_sco-tester PASS 141.48 seconds
TestRunner_ioctl-tester PASS 133.21 seconds
TestRunner_mesh-tester PASS 59.62 seconds
TestRunner_smp-tester PASS 17.73 seconds
TestRunner_userchan-tester PASS 19.12 seconds
TestRunner_6lowpan-tester PASS 51.01 seconds
IncrementalBuild PASS 26.59 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v2] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?
total: 0 errors, 1 warnings, 0 checks, 34 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/14585274.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.
https://github.com/bluez/bluetooth-next/pull/223
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Jakub Kicinski @ 2026-05-21 0:26 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
In-Reply-To: <20260521001327.3729880-1-michael.bommarito@gmail.com>
On Wed, 20 May 2026 20:13:27 -0400 Michael Bommarito wrote:
> From: Michael Bommarito <michael.bommarito@gmail.com>
Please (tell your bot to) use the get_maintainer script.
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-20
From: patchwork-bot+netdevbpf @ 2026-05-21 0:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260520204959.2902497-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 20 May 2026 16:49:58 -0400 you wrote:
> The following changes since commit 375ba7484132662a4a8c7547d088fb6275c00282:
>
> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-20
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-05-20
https://git.kernel.org/netdev/net/c/5027c886e26c
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: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Michael Bommarito @ 2026-05-21 0:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
In-Reply-To: <20260520172609.3034337f@kernel.org>
On Wed, May 20, 2026 at 8:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
> Please (tell your bot to) use the get_maintainer script.
It (and I) did, but I think this is because net/bluetooth/ matches net/, right?
Here's what I see when I run it. Is there a different set of args
that I should be using for netdev or net/bluetooth/ in particular?
Marcel Holtmann <marcel@holtmann.org> (maintainer:BLUETOOTH SUBSYSTEM)
Luiz Augusto von Dentz <luiz.dentz@gmail.com> (maintainer:BLUETOOTH SUBSYSTEM)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING [GENERAL])
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING [GENERAL])
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING [GENERAL])
Simon Horman <horms@kernel.org> (reviewer:NETWORKING [GENERAL])
linux-bluetooth@vger.kernel.org (open list:BLUETOOTH SUBSYSTEM)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-kernel@vger.kernel.org (open list)
Or did you mean because of Fixes:? This dates back to original git
import commit, so I thought the practice is to skip a Fixes: tag
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: Jakub Kicinski @ 2026-05-21 0:42 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
In-Reply-To: <CAJJ9bXy1xQsfRd_DBiFjTj6GjkDDVFU3w_5xjXvZmp8CXnkz5g@mail.gmail.com>
On Wed, 20 May 2026 20:32:28 -0400 Michael Bommarito wrote:
> On Wed, May 20, 2026 at 8:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > Please (tell your bot to) use the get_maintainer script.
>
> It (and I) did, but I think this is because net/bluetooth/ matches net/, right?
Looks like we're missing an X, sorry.
^ permalink raw reply
* RE: [v3] Bluetooth: HIDP: fix missing length checks in hidp_input_report()
From: bluez.test.bot @ 2026-05-21 1:24 UTC (permalink / raw)
To: linux-bluetooth, meatuni001
In-Reply-To: <20260520225643.35683-1-meatuni001@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1482 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=1098338
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.12 seconds
BuildKernel PASS 25.49 seconds
CheckAllWarning PASS 28.49 seconds
CheckSparse PASS 26.31 seconds
BuildKernel32 PASS 24.53 seconds
TestRunnerSetup PASS 525.22 seconds
TestRunner_l2cap-tester PASS 378.59 seconds
TestRunner_iso-tester PASS 597.04 seconds
TestRunner_bnep-tester PASS 19.00 seconds
TestRunner_mgmt-tester PASS 2023.48 seconds
TestRunner_rfcomm-tester PASS 63.40 seconds
TestRunner_sco-tester PASS 141.63 seconds
TestRunner_ioctl-tester PASS 133.58 seconds
TestRunner_mesh-tester PASS 60.44 seconds
TestRunner_smp-tester PASS 17.83 seconds
TestRunner_userchan-tester PASS 19.21 seconds
TestRunner_6lowpan-tester PASS 50.92 seconds
IncrementalBuild PASS 24.01 seconds
https://github.com/bluez/bluetooth-next/pull/224
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: Siwei Zhang @ 2026-05-21 1:56 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Safa Karakuş, stable
In-Reply-To: <CABBYNZJiCTJrde9rYT=NQAk_RUv=ugeAUPnRg6vsjvU5hW4NqQ@mail.gmail.com>
Hi Luiz,
On Wed, May 20, 2026, at 4:29 PM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, May 20, 2026 at 4:06 PM Siwei Zhang <oss@fourdim.xyz> 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.
>>
>> The timer is only armed when chan->conn is still set: if it is
>> already NULL, l2cap_conn_del() has already processed this channel
>> (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb),
>> so there is nothing left to do. If l2cap_conn_del() races in
>> after the timer is armed, __clear_chan_timer() inside
>> l2cap_chan_del() cancels it; if the timer has already fired, the
>> handler returns harmlessly because chan->conn was cleared.
>>
>> Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
>> ---
>> net/bluetooth/l2cap_sock.c | 16 +++++++++-------
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
>> index 4ed745a9c2cf..025329636353 100644
>> --- a/net/bluetooth/l2cap_sock.c
>> +++ b/net/bluetooth/l2cap_sock.c
>> @@ -1512,6 +1512,10 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
>> * pin it (hold_unless_zero() additionally skips a chan already past
>> * its last reference). We then drop the sk lock before taking
>> * chan->lock, so sk and chan locks are never held together.
>> + *
>> + * Since we cannot call l2cap_chan_close() without conn->lock,
>> + * schedule l2cap_chan_timeout to close the channel; it already
>> + * acquires conn->lock -> chan->lock in the correct order.
>> */
>> while ((sk = bt_accept_dequeue(parent, NULL))) {
>> struct l2cap_chan *chan;
>> @@ -1529,14 +1533,12 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
>> state_to_string(chan->state));
>>
>> l2cap_chan_lock(chan);
>> - __clear_chan_timer(chan);
>> - l2cap_chan_close(chan, ECONNRESET);
>> - /* l2cap_conn_del() may already have killed this socket
>> - * (it sets SOCK_DEAD); skip the duplicate to avoid a
>> - * double sock_put()/l2cap_chan_put().
>> + /* Since we cannot call l2cap_chan_close() without
>> + * conn->lock, schedule its timer to trigger the close
>> + * and cleanup of this channel.
>> */
>> - if (!sock_flag(sk, SOCK_DEAD))
>> - l2cap_sock_kill(sk);
>> + if (chan->conn)
>> + __set_chan_timer(chan, 0);
>
> Great that seems a lot easier to understand than the previous changes.
> I just don't quite follow why you are removing SOCK_DEAD handling with
> this?
>
l2cap_sock_cleanup_listen() [holds: parent sk_lock]
bt_accept_dequeue() → returns child sk + ref
lock_sock(child sk)
l2cap_chan_hold_unless_zero(chan)
release_sock(child sk)
l2cap_chan_lock(chan)
__set_chan_timer(chan, 0) → schedules delayed work
l2cap_chan_unlock(chan)
l2cap_chan_put(chan)
sock_put(sk)
↓ (deferred, on workqueue)
l2cap_chan_timeout()
mutex_lock(conn->lock) ← proper lock order
l2cap_chan_lock(chan)
l2cap_chan_close(chan, reason)
l2cap_chan_del(chan, reason)
chan->ops->teardown(chan, err) → l2cap_sock_teardown_cb()
lock_sock(child sk)
sk->sk_state = BT_CLOSED
sock_set_flag(sk, SOCK_ZAPPED)
release_sock(sk)
chan->ops->close(chan) → l2cap_sock_close_cb()
l2cap_sock_kill(sk)
chan->data = NULL
l2cap_chan_put(chan)
sock_set_flag(sk, SOCK_DEAD)
sock_put(sk)
l2cap_chan_timeout() will do the l2cap_sock_kill() job for us.
Previously in Safa's patch, because that does not have conn-lock
protection, which might result in double kill so there is a defensive
check. In our version, this is totally not required.
>> l2cap_chan_unlock(chan);
>>
>> l2cap_chan_put(chan);
>> --
>> 2.54.0
>>
>
>
> --
> Luiz Augusto von Dentz
Best,
Siwei
^ permalink raw reply
* [PATCH v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: Siwei Zhang @ 2026-05-21 2:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, safa.karakus, stable, Siwei Zhang
In-Reply-To: <CABBYNZJiCTJrde9rYT=NQAk_RUv=ugeAUPnRg6vsjvU5hW4NqQ@mail.gmail.com>
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.
The timer is only armed when chan->conn is still set: if it is
already NULL, l2cap_conn_del() has already processed this channel
(l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb),
so there is nothing left to do. If l2cap_conn_del() races in
after the timer is armed, __clear_chan_timer() inside
l2cap_chan_del() cancels it; if the timer has already fired, the
handler returns harmlessly because chan->conn was cleared.
Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list")
Cc: <stable@vger.kernel.org> # 0b58004: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
net/bluetooth/l2cap_sock.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 4ed745a9c2cf..025329636353 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1512,6 +1512,10 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
* pin it (hold_unless_zero() additionally skips a chan already past
* its last reference). We then drop the sk lock before taking
* chan->lock, so sk and chan locks are never held together.
+ *
+ * Since we cannot call l2cap_chan_close() without conn->lock,
+ * schedule l2cap_chan_timeout to close the channel; it already
+ * acquires conn->lock -> chan->lock in the correct order.
*/
while ((sk = bt_accept_dequeue(parent, NULL))) {
struct l2cap_chan *chan;
@@ -1529,14 +1533,12 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
state_to_string(chan->state));
l2cap_chan_lock(chan);
- __clear_chan_timer(chan);
- l2cap_chan_close(chan, ECONNRESET);
- /* l2cap_conn_del() may already have killed this socket
- * (it sets SOCK_DEAD); skip the duplicate to avoid a
- * double sock_put()/l2cap_chan_put().
+ /* Since we cannot call l2cap_chan_close() without
+ * conn->lock, schedule its timer to trigger the close
+ * and cleanup of this channel.
*/
- if (!sock_flag(sk, SOCK_DEAD))
- l2cap_sock_kill(sk);
+ if (chan->conn)
+ __set_chan_timer(chan, 0);
l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btmtk: remove extra copy in cmd array init
From: Jiajia Liu @ 2026-05-21 2:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <CABBYNZLLNFNuSv0UBNQ7C2HTTg5W2m41hBTNpPw822GMAVNuhQ@mail.gmail.com>
On Wed, May 20, 2026 at 08:55:46AM -0400, Luiz Augusto von Dentz wrote:
> 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.
Yes, I have tested with MT7922 (0489:e0d8) on linux 7.1-rc4 applied this patch
and the following two.
Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
Bluetooth: btmtk: fix urb->setup_packet leak in error paths
setup log of boot and rfkill switch:
$ dmesg | grep hci0
[ 6.108240] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
[ 8.933508] Bluetooth: hci0: Device setup in 2765295 usecs
[ 8.938846] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[ 57.209143] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
[ 57.366004] Bluetooth: hci0: Device setup in 160450 usecs
[ 57.371248] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[ 203.687643] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
[ 203.844163] Bluetooth: hci0: Device setup in 158989 usecs
[ 203.849426] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[ 214.723250] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
[ 214.879380] Bluetooth: hci0: Device setup in 155239 usecs
[ 214.884644] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
From: Siwei Zhang @ 2026-05-21 2:30 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz; +Cc: linux-bluetooth, Siwei Zhang
__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.
Fixes: adf0398cee86 ("Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout")
Cc: stable@vger.kernel.org
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
net/bluetooth/l2cap_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index fdccd62ccca8..5668c92b3f58 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -411,8 +411,10 @@ static void l2cap_chan_timeout(struct work_struct *work)
BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
- if (!conn)
+ if (!conn) {
+ l2cap_chan_put(chan);
return;
+ }
mutex_lock(&conn->lock);
/* __set_chan_timer() calls l2cap_chan_hold(chan) while scheduling
--
2.54.0
^ permalink raw reply related
* [PATCH BlueZ 1/2] shared/bap: Fix unused value in qos
From: michael_kong @ 2026-05-21 3:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: michael_kong
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(-)
diff --git a/src/shared/bap.c b/src/shared/bap.c
index 78ba22259..bd523e5e6 100644
--- a/src/shared/bap.c
+++ b/src/shared/bap.c
@@ -7655,16 +7655,15 @@ bool bt_bap_parse_base(uint8_t sid, struct iovec *iov,
bt_bap_bis_func_t handler,
void *user_data)
{
- uint32_t delay;
uint8_t sgrps;
bool ret = true;
util_debug(func, NULL, "BASE len: %zd", iov->iov_len);
- if (!util_iov_pull_le24(iov, &delay))
+ if (!util_iov_pull_le24(iov, &qos->bcast.delay))
return false;
- util_debug(func, NULL, "PresentationDelay: %d", delay);
+ util_debug(func, NULL, "PresentationDelay: %d", qos->bcast.delay);
if (!util_iov_pull_u8(iov, &sgrps))
return false;
--
2.29.1.windows.1
^ permalink raw reply related
* [PATCH BlueZ 2/2] transport: Add support for obtaining PresentationDelay in broadcast QoS
From: michael_kong @ 2026-05-21 3:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: michael_kong
In-Reply-To: <20260521032815.1845-1-kx960506@163.com>
---
profiles/audio/transport.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
index 3cb4ab0e2..4b9d26c5e 100644
--- a/profiles/audio/transport.c
+++ b/profiles/audio/transport.c
@@ -1605,6 +1605,8 @@ static gboolean get_bcast_qos(const GDBusPropertyTable *property,
&bap->qos.bcast.mse);
dict_append_entry(&dict, "Timeout", DBUS_TYPE_UINT16,
&bap->qos.bcast.timeout);
+ dict_append_entry(&dict, "PresentationDelay", DBUS_TYPE_UINT32,
+ &bap->qos.bcast.delay);
append_io_qos(&dict, &bap->qos.bcast.io_qos);
--
2.29.1.windows.1
^ permalink raw reply related
* RE: [v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: bluez.test.bot @ 2026-05-21 3:57 UTC (permalink / raw)
To: linux-bluetooth, oss
In-Reply-To: <20260521021249.3258069-1-oss@fourdim.xyz>
[-- Attachment #1: Type: text/plain, Size: 555 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: net/bluetooth/l2cap_sock.c:1512
error: net/bluetooth/l2cap_sock.c: 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: [v2] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
From: Siwei Zhang @ 2026-05-21 4:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Luiz Augusto von Dentz
In-Reply-To: <6a0e82a1.131d4d69.3874c7.d8ed@mx.google.com>
On Wed, May 20, 2026, at 11:57 PM, bluez.test.bot@gmail.com wrote:
> 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: net/bluetooth/l2cap_sock.c:1512
> error: net/bluetooth/l2cap_sock.c: 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
I think it is false positive as I rebased against latest bluetooth-next.
Best,
Siwei
^ permalink raw reply
* RE: Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
From: bluez.test.bot @ 2026-05-21 4:27 UTC (permalink / raw)
To: linux-bluetooth, oss
In-Reply-To: <20260521023055.3272712-1-oss@fourdim.xyz>
[-- Attachment #1: Type: text/plain, Size: 937 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=1098397
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
GitLint PASS 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.59 seconds
CheckAllWarning PASS 27.76 seconds
CheckSparse PASS 26.46 seconds
BuildKernel32 PASS 24.69 seconds
TestRunnerSetup PASS 530.44 seconds
TestRunner_l2cap-tester PASS 374.90 seconds
IncrementalBuild PASS 24.34 seconds
https://github.com/bluez/bluetooth-next/pull/226
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: bluez.test.bot @ 2026-05-21 4:27 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260521001327.3729880-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2652 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=1098364
---Test result---
Test Summary:
CheckPatch FAIL 1.00 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.25 seconds
CheckAllWarning PASS 28.83 seconds
CheckSparse PASS 27.41 seconds
BuildKernel32 PASS 25.53 seconds
TestRunnerSetup PASS 526.88 seconds
TestRunner_l2cap-tester PASS 376.33 seconds
IncrementalBuild PASS 24.88 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] 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, 66 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/14585530.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: L2CAP: 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
38: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
39: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
73: B1 Line exceeds max length (82>80): "v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
74: B1 Line exceeds max length (82>80): "v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
https://github.com/bluez/bluetooth-next/pull/225
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: btusb: Allow firmware re-download when version matches
From: Shuai Zhang @ 2026-05-21 5:25 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, linux-arm-msm, cheng.jiang,
quic_chezhou, wei.deng, jinwang.li, mengshi.wu, shuai.zhang,
stable
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.
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.
Fixes: 3267c884cefa ("Bluetooth: btusb: Add support for QCA ROME chipset family")
Cc: stable@vger.kernel.org
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
Changes v3:
- Add Fixes tag pointing to the commit that introduced the version
comparison.
- Link v2
https://lore.kernel.org/all/20260429121207.1306526-1-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) {
bt_dev_err(hdev, "rampatch file version did not match with firmware");
err = -EINVAL;
goto done;
--
2.34.1
^ permalink raw reply related
* [PATCH v4] Bluetooth: bnep: reject short frames before parsing
From: Zhang Cen @ 2026-05-21 5:26 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, zerocling0077, 2045gemini,
Zhang Cen
A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the
packet type byte immediately and, for control packets, reads the control
opcode and setup UUID-size byte before proving that those bytes are
present. bnep_rx_control() also dereferences the control opcode without
rejecting an empty control payload.
Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL
return gates each dereference. Split the control handler so the frame
path can pass an opcode that has already been pulled, and keep the
byte-buffer wrapper for extension control payloads.
Validation reproduced this kernel report:
KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790
The buggy address belongs to the object at ffff88800c0f7908 which belongs
to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes to the right of allocated 1-byte
region [ffff88800c0f7908, ffff88800c0f7909)
Read of size 1
Call trace:
dump_stack_lvl+0xb3/0x140 (?:?)
print_address_description+0x57/0x3a0 (?:?)
bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)
print_report+0xb9/0x2b0 (?:?)
__virt_addr_valid+0x1ba/0x3a0 (?:?)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
kasan_addr_to_slab+0x21/0x60 (?:?)
kasan_report+0xe0/0x110 (?:?)
process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)
worker_thread+0x65c/0xe40 (?:?)
__kthread_parkme+0x184/0x230 (?:?)
kthread+0x35e/0x470 (?:?)
_raw_spin_unlock_irq+0x28/0x50 (?:?)
ret_from_fork+0x586/0x870 (?:?)
__switch_to+0x74f/0xdc0 (?:?)
ret_from_fork_asm+0x1a/0x30 (?:?)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
---
net/bluetooth/bnep/core.c | 51 ++++++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
index 853c8d764..156cd3026 100644
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -206,14 +206,11 @@ static int bnep_ctrl_set_mcfilter(struct bnep_session *s, u8 *data, int len)
return 0;
}
-static int bnep_rx_control(struct bnep_session *s, void *data, int len)
+static int bnep_rx_control_cmd(struct bnep_session *s, u8 cmd, void *data,
+ int len)
{
- u8 cmd = *(u8 *)data;
int err = 0;
- data++;
- len--;
-
switch (cmd) {
case BNEP_CMD_NOT_UNDERSTOOD:
case BNEP_SETUP_CONN_RSP:
@@ -254,6 +251,14 @@ static int bnep_rx_control(struct bnep_session *s, void *data, int len)
return err;
}
+static int bnep_rx_control(struct bnep_session *s, void *data, int len)
+{
+ if (len < 1)
+ return -EILSEQ;
+
+ return bnep_rx_control_cmd(s, *(u8 *)data, data + 1, len - 1);
+}
+
static int bnep_rx_extension(struct bnep_session *s, struct sk_buff *skb)
{
struct bnep_ext_hdr *h;
@@ -299,19 +304,26 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
{
struct net_device *dev = s->dev;
struct sk_buff *nskb;
+ u8 *data;
u8 type, ctrl_type;
dev->stats.rx_bytes += skb->len;
- type = *(u8 *) skb->data;
- skb_pull(skb, 1);
- ctrl_type = *(u8 *)skb->data;
+ data = skb_pull_data(skb, sizeof(type));
+ if (!data)
+ goto badframe;
+ type = *data;
if ((type & BNEP_TYPE_MASK) >= sizeof(__bnep_rx_hlen))
goto badframe;
if ((type & BNEP_TYPE_MASK) == BNEP_CONTROL) {
- if (bnep_rx_control(s, skb->data, skb->len) < 0) {
+ data = skb_pull_data(skb, sizeof(ctrl_type));
+ if (!data)
+ goto badframe;
+ ctrl_type = *data;
+
+ if (bnep_rx_control_cmd(s, ctrl_type, skb->data, skb->len) < 0) {
dev->stats.tx_errors++;
kfree_skb(skb);
return 0;
@@ -325,23 +337,22 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
/* Verify and pull ctrl message since it's already processed */
switch (ctrl_type) {
case BNEP_SETUP_CONN_REQ:
- /* Pull: ctrl type (1 b), len (1 b), data (len bytes) */
- if (!skb_pull(skb, 2 + *(u8 *)(skb->data + 1) * 2))
+ /* Pull: len (1 b), data (len * 2 bytes) */
+ data = skb_pull_data(skb, 1);
+ if (!data)
+ goto badframe;
+ if (!skb_pull(skb, *data * 2))
goto badframe;
break;
case BNEP_FILTER_MULTI_ADDR_SET:
- case BNEP_FILTER_NET_TYPE_SET: {
- u8 *hdr;
-
- /* Pull ctrl type (1 b) + len (2 b) */
- hdr = skb_pull_data(skb, 3);
- if (!hdr)
+ case BNEP_FILTER_NET_TYPE_SET:
+ /* Pull: len (2 b), data (len bytes) */
+ data = skb_pull_data(skb, sizeof(u16));
+ if (!data)
goto badframe;
- /* Pull data (len bytes); length is big-endian */
- if (!skb_pull(skb, get_unaligned_be16(&hdr[1])))
+ if (!skb_pull(skb, get_unaligned_be16(data)))
goto badframe;
break;
- }
default:
kfree_skb(skb);
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: Shuai Zhang @ 2026-05-21 5:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
In-Reply-To: <CABBYNZJpW8=KtN9_G2QOp1YqD3ZJhWGVriyLBh7jUGRFEHPyYg@mail.gmail.com>
Hi Luiz
On 5/20/2026 8:45 PM, Luiz Augusto von Dentz wrote:
> 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.
From my understanding, the current changes should already cover this case,
so no further modifications seem necessary. Please let me know if you
see it differently.
I will add a Fixes tag in the next revision.
>>>> 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
>>
Thanks,
Shuai
>
>
^ permalink raw reply
* [bluez/bluez] 35baf7: shared/bap: Fix unused value in qos
From: michael kong @ 2026-05-21 5:50 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1098419
Home: https://github.com/bluez/bluez
Commit: 35baf761c1f830861a6bcacf856c4c95029148f9
https://github.com/bluez/bluez/commit/35baf761c1f830861a6bcacf856c4c95029148f9
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: e58872a259ad0973107ef479b33a4e2be273bbf6
https://github.com/bluez/bluez/commit/e58872a259ad0973107ef479b33a4e2be273bbf6
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
Compare: https://github.com/bluez/bluez/compare/35baf761c1f8%5E...e58872a259ad
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ] doc: Fix Data Path direction in btmin-le-audio.rst
From: michael_kong @ 2026-05-21 6:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: michael_kong
The Data Path direction 0x01 should be Output (Controller to Host).
---
doc/btmon-le-audio.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/btmon-le-audio.rst b/doc/btmon-le-audio.rst
index 50ee11879..47213c92e 100644
--- a/doc/btmon-le-audio.rst
+++ b/doc/btmon-le-audio.rst
@@ -454,12 +454,12 @@ On success, the controller assigns BIS connection handles (0x0010,
< HCI Command: LE Setup ISO Data Path (0x08|0x006e) plen 13 #140 [hci0] 0.500003
Connection Handle: 0x0010
- Data Path Direction: Output (Host to Controller) (0x01)
+ Data Path Direction: Output (Controller to Host) (0x01)
Data Path ID: HCI (0x00)
< HCI Command: LE Setup ISO Data Path (0x08|0x006e) plen 13 #145 [hci0] 0.550003
Connection Handle: 0x0011
- Data Path Direction: Output (Host to Controller) (0x01)
+ Data Path Direction: Output (Controller to Host) (0x01)
Data Path ID: HCI (0x00)
**Step 8 -- ISO Data flows** on BIS handles::
--
2.29.1.windows.1
^ 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