* [PATCH v2] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Muhammad Bilal @ 2026-05-19 7:30 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, marcel, luiz.dentz, kees, kuba, stable,
Muhammad Bilal
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
immediately dereferences hdr->addr and hdr->ctrl without first
validating that skb->len is large enough to hold the header. A
remote device can send a crafted short RFCOMM frame over L2CAP to
trigger an out-of-bounds read before any session state is checked.
The FCS trimming code that follows compounds the problem:
skb->len--; skb->tail--;
If skb->len is already zero the decrement wraps to UINT_MAX, causing
skb_tail_pointer() to return a pointer far outside the skb and
producing a second out-of-bounds read when the FCS byte is consumed.
Add a minimum length check before the header pointer is assigned. A
well-formed RFCOMM frame requires at least addr(1) + ctrl(1) +
len(1) + fcs(1) = sizeof(struct rfcomm_hdr) + 1 bytes. This single
guard prevents both the header out-of-bounds read and the skb->len
integer underflow.
Note: SeungJu Cheon posted a related patch that adds equivalent
length checks inside the individual MCC sub-handlers
(rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
rfcomm_recv_mcc). That fix and this one are complementary and
independent; neither subsumes the other.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
net/bluetooth/rfcomm/core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337..6b300237c 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1741,7 +1741,7 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
struct sk_buff *skb)
{
- struct rfcomm_hdr *hdr = (void *) skb->data;
+ struct rfcomm_hdr *hdr;
u8 type, dlci, fcs;
if (!s) {
@@ -1750,10 +1750,17 @@ static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
return s;
}
+ /* Minimum valid frame: addr(1) + ctrl(1) + len(1) + fcs(1) */
+ if (skb->len < sizeof(*hdr) + 1) {
+ kfree_skb(skb);
+ return s;
+ }
+
+ hdr = (void *) skb->data;
dlci = __get_dlci(hdr->addr);
type = __get_type(hdr->ctrl);
- /* Trim FCS */
+ /* Trim FCS - safe: skb->len >= sizeof(*hdr) + 1 >= 1 */
skb->len--; skb->tail--;
fcs = *(u8 *)skb_tail_pointer(skb);
--
2.54.0
^ permalink raw reply related
* [PATCH v2] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Muhammad Bilal @ 2026-05-19 7:25 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, marcel, luiz.dentz, kees, kuba, stable,
Muhammad Bilal
In-Reply-To: <20260519042017.29564-1-meatuni001@gmail.com>
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
immediately dereferences hdr->addr and hdr->ctrl without first
validating that skb->len is large enough to hold the header. A
remote device can send a crafted short RFCOMM frame over L2CAP to
trigger an out-of-bounds read before any session state is checked.
The FCS trimming code that follows compounds the problem:
skb->len--; skb->tail--;
If skb->len is already zero the decrement wraps to UINT_MAX, causing
skb_tail_pointer() to return a pointer far outside the skb and
producing a second out-of-bounds read when the FCS byte is consumed.
Add a minimum length check before the header pointer is assigned. A
well-formed RFCOMM frame requires at least addr(1) + ctrl(1) +
len(1) + fcs(1) = sizeof(struct rfcomm_hdr) + 1 bytes. This single
guard prevents both the header out-of-bounds read and the skb->len
integer underflow.
Note: SeungJu Cheon posted a related patch that adds equivalent
length checks inside the individual MCC sub-handlers
(rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
rfcomm_recv_mcc). That fix and this one are complementary and
independent; neither subsumes the other.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
net/bluetooth/rfcomm/core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337..6b300237c 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1741,7 +1741,7 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
struct sk_buff *skb)
{
- struct rfcomm_hdr *hdr = (void *) skb->data;
+ struct rfcomm_hdr *hdr;
u8 type, dlci, fcs;
if (!s) {
@@ -1750,10 +1750,17 @@ static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
return s;
}
+ /* Minimum valid frame: addr(1) + ctrl(1) + len(1) + fcs(1) */
+ if (skb->len < sizeof(*hdr) + 1) {
+ kfree_skb(skb);
+ return s;
+ }
+
+ hdr = (void *) skb->data;
dlci = __get_dlci(hdr->addr);
type = __get_type(hdr->ctrl);
- /* Trim FCS */
+ /* Trim FCS - safe: skb->len >= sizeof(*hdr) + 1 >= 1 */
skb->len--; skb->tail--;
fcs = *(u8 *)skb_tail_pointer(skb);
--
2.54.0
^ permalink raw reply related
* Re: [GIT PULL] bluetooth 2026-05-14
From: Thorsten Leemhuis @ 2026-05-19 7:04 UTC (permalink / raw)
To: Greg KH, stable@vger.kernel.org, Sasha Levin
Cc: linux-bluetooth, netdev, Luiz Augusto von Dentz, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <f5cf1c30-48a4-4102-ae00-b74cf02e639e@leemhuis.info>
On 5/15/26 17:10, Thorsten Leemhuis wrote:
> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>
>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>
>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>
>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>
> It seems this PR sadly came too late for this week's net PR to mainline
> that was merged yesterday.
>
> TWIMC, from my point of view, it would be great if we somehow could
> still get the changes from this PR or at least the btmtk fix it
> contains[1] to mainline this week before -rc4, as it is fixing a
> regression known since 2026-04-24 that at least five people encountered
> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> validate WMT event SKB length before struct access") [006b9943b982 in
> -next].
Greg, Sasha, that [1] fix I was talking about now reached -next as
162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
events") and will likely hit mainline on Thursday or so with the weekly
-net PR to -mainline. If that's good enough for you, I'd say it would be
good to pick this up for the next round of stable kernels.
Ciao, Thorsten
P.S.: Side note, in case anyone cares: this regression meanwhile was
reported at least 14 times by now (only counting upstream reports, there
are many more in various downstreams).
> Another reason: Greg a few hours ago backported the culprit for the
> regression to v7.0.7, v6.18.30, and v6.12.88, which led to a bunch of
> other reports coming in[3]. Greg could, of course, revert it, but
> usually he prefers to just merge the fix. But of course the fix must
> first hit mainline (or at least -next) -- and that might only happen
> next Thursday, as there usually is only one net PR per week. Luiz even
> wanted to "expedite a PR to have it fixed asap"[4], but that didn't work
> out afaics, hence this mail.
>
> Ciao, Thorsten
>
> [1] btmtk: accept too short WMT FUNC_CTRL events – also available here:
> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
>
> [2]
> https://lore.kernel.org/lkml/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> https://lore.kernel.org/lkml/f652d5d9841a9b7c100dd19ee97c86099f580724.camel@gmail.com/
> https://bugzilla.kernel.org/show_bug.cgi?id=221511
> https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
> https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
> (+ one more report in a Fedora kernel chatroom)
>
> [3]
> https://bugzilla.kernel.org/show_bug.cgi?id=221521
> https://lore.kernel.org/lkml/51b55b97-615b-4f5e-b454-df646f4058b7@augustwikerfors.se/
> + a four more people in
> https://bodhi.fedoraproject.org/updates/FEDORA-2026-6b173ffc2a#comment-4646633
>
> [4]
> https://lore.kernel.org/all/CABBYNZ+FfhYtU2=J-V4pjKf_vKV=Y5LhVhxS_epKe-qaUUt8_g@mail.gmail.com/
>
>
>> ----------------------------------------------------------------
>> bluetooth pull request for net:
>>
>> - af_bluetooth: serialize accept_q access
>> - L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
>> - btmtk: accept too short WMT FUNC_CTRL events
>> - hci_qca: Convert timeout from jiffies to ms
>>
>> ----------------------------------------------------------------
>> Jiexun Wang (1):
>> Bluetooth: serialize accept_q access
>>
>> Michael Bommarito (1):
>> Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
>>
>> Pauli Virtanen (1):
>> Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
>>
>> Shuai Zhang (1):
>> Bluetooth: hci_qca: Convert timeout from jiffies to ms
>>
>> drivers/bluetooth/btmtk.c | 4 +-
>> drivers/bluetooth/hci_qca.c | 33 +++++++--------
>> include/net/bluetooth/bluetooth.h | 1 +
>> net/bluetooth/af_bluetooth.c | 87 +++++++++++++++++++++++++++++----------
>> net/bluetooth/l2cap_core.c | 2 +-
>> 5 files changed, 85 insertions(+), 42 deletions(-)
>>
>
^ permalink raw reply
* RE: Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: bluez.test.bot @ 2026-05-19 6:15 UTC (permalink / raw)
To: linux-bluetooth, meatuni001
In-Reply-To: <20260519042017.29564-1-meatuni001@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1523 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=1097025
---Test result---
Test Summary:
CheckPatch PASS 0.50 seconds
GitLint FAIL 0.22 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 29.00 seconds
CheckAllWarning PASS 28.96 seconds
CheckSparse PASS 27.22 seconds
BuildKernel32 PASS 25.35 seconds
TestRunnerSetup PASS 568.42 seconds
TestRunner_rfcomm-tester PASS 63.54 seconds
IncrementalBuild PASS 24.24 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
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
11: B3 Line contains hard tab characters (\t): " skb->len--; skb->tail--;"
https://github.com/bluez/bluetooth-next/pull/213
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-19 5:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Jiri Slaby (jirislaby@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jirislaby@gmail.com
--- Comment #11 from Jiri Slaby (jirislaby@gmail.com) ---
It's not in linus/master, so cannot be in stable. Once it hits linus' tree,
stable will be poked to pick it up.
Meanwhile backporting to openSUSE.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [REGRESSION] Bluetooth: MT7922 fails to initialize after "Bluetooth: btmtk: validate WMT event SKB length before struct access"
From: Thorsten Leemhuis @ 2026-05-19 5:04 UTC (permalink / raw)
To: Baley Eccles, linux-bluetooth
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek, regressions, stable
In-Reply-To: <CADCSNFD0Ut-jJohTQFczjBgaVf=mBrc2rq4hJQncVZpF4bCoxw@mail.gmail.com>
On 5/19/26 06:31, Baley Eccles wrote:
> Subject: [REGRESSION] Bluetooth: MT7922 fails to initialize after
> "Bluetooth: btmtk: validate WMT event SKB length before struct access"
>
> Hi all,
>
> I have experienced and looked into a regression on a MediaTek MT7922
> adapter. Bluetooth works on v6.18.29, fails on v6.18.30, and reverting
> the bisected commit fixes it.
Thx for the report, there are quite a few similar ones already; the
problem is known and the fix (see the link below) should be heading to
mainline this week and from there go to various stable series.
Ciao, Thorsten
#regzbot dup:
https://lore.kernel.org/linux-bluetooth/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
> Hardware:
> MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:7922]
> Subsystem: AzureWave ASUS PCE-AXE59BT [1a3b:5300]
>
> Good kernel:
> 6.18.29-p2-gentoo-dist
> Upstream base: v6.18.29
>
> Bad kernel:
> 6.18.30-p1-gentoo-dist
> Upstream base: v6.18.30
>
> Failure:
> bluetoothctl list prints nothing / no default controller is available.
>
> Bad dmesg:
> Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
> Bluetooth: hci0: Failed to send wmt func ctrl (-22)
> Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
> advertised, but not supported.
>
> Good dmesg:
> Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
> Bluetooth: hci0: Device setup in 129909 usecs
> Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
> advertised, but not supported.
> Bluetooth: hci0: AOSP extensions version v1.00
> Bluetooth: hci0: AOSP quality report is supported
> Bluetooth: MGMT ver 1.23
>
> Firmware:
> /lib/firmware/mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
> /lib/firmware/mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin
> /lib/firmware/mediatek/WIFI_RAM_CODE_MT7922_1.bin
>
> Bisect result:
> 624fb79dadc1b65757986a9d0fdde5c0cf3fe179 is the first bad commit
>
> Bluetooth: btmtk: validate WMT event SKB length before struct access
>
> This is a stable backport of upstream commit:
> 634a4408c0615c523cf7531790f4f14a422b9206
>
> Reverting 624fb79dadc1b65757986a9d0fdde5c0cf3fe179 on top of v6.18.30
> fixes the issue and Bluetooth works again.
>
> Please let me know if there is any additional logging or testing I can provide.
>
> #regzbot introduced: 624fb79dadc1b65757986a9d0fdde5c0cf3fe179
>
> Cheers,
> Baley
^ permalink raw reply
* [REGRESSION] Bluetooth: MT7922 fails to initialize after "Bluetooth: btmtk: validate WMT event SKB length before struct access"
From: Baley Eccles @ 2026-05-19 4:31 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek, regressions, stable
Subject: [REGRESSION] Bluetooth: MT7922 fails to initialize after
"Bluetooth: btmtk: validate WMT event SKB length before struct access"
Hi all,
I have experienced and looked into a regression on a MediaTek MT7922
adapter. Bluetooth works on v6.18.29, fails on v6.18.30, and reverting
the bisected commit fixes it.
Hardware:
MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:7922]
Subsystem: AzureWave ASUS PCE-AXE59BT [1a3b:5300]
Good kernel:
6.18.29-p2-gentoo-dist
Upstream base: v6.18.29
Bad kernel:
6.18.30-p1-gentoo-dist
Upstream base: v6.18.30
Failure:
bluetoothctl list prints nothing / no default controller is available.
Bad dmesg:
Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
Bluetooth: hci0: Failed to send wmt func ctrl (-22)
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
advertised, but not supported.
Good dmesg:
Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
Bluetooth: hci0: Device setup in 129909 usecs
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
advertised, but not supported.
Bluetooth: hci0: AOSP extensions version v1.00
Bluetooth: hci0: AOSP quality report is supported
Bluetooth: MGMT ver 1.23
Firmware:
/lib/firmware/mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
/lib/firmware/mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin
/lib/firmware/mediatek/WIFI_RAM_CODE_MT7922_1.bin
Bisect result:
624fb79dadc1b65757986a9d0fdde5c0cf3fe179 is the first bad commit
Bluetooth: btmtk: validate WMT event SKB length before struct access
This is a stable backport of upstream commit:
634a4408c0615c523cf7531790f4f14a422b9206
Reverting 624fb79dadc1b65757986a9d0fdde5c0cf3fe179 on top of v6.18.30
fixes the issue and Bluetooth works again.
Please let me know if there is any additional logging or testing I can provide.
#regzbot introduced: 624fb79dadc1b65757986a9d0fdde5c0cf3fe179
Cheers,
Baley
^ permalink raw reply
* [PATCH] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Muhammad Bilal @ 2026-05-19 4:20 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, Marcel Holtmann, Luiz Augusto von Dentz,
Kees Cook, Jakub Kicinski, Muhammad Bilal
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
immediately dereferences hdr->addr and hdr->ctrl without first
validating that skb->len is large enough to hold the header. A
remote device can send a crafted short RFCOMM frame over L2CAP to
trigger an out-of-bounds read before any session state is checked.
The FCS trimming code that follows compounds the problem:
skb->len--; skb->tail--;
If skb->len is already zero the decrement wraps to UINT_MAX, causing
skb_tail_pointer() to return a pointer far outside the skb and
producing a second out-of-bounds read when the FCS byte is consumed.
Add a minimum length check before the header pointer is assigned. A
well-formed RFCOMM frame requires at least addr(1) + ctrl(1) +
len(1) + fcs(1) = sizeof(struct rfcomm_hdr) + 1 bytes. This single
guard prevents both the header out-of-bounds read and the skb->len
integer underflow.
Note: SeungJu Cheon posted a related patch that adds equivalent
length checks inside the individual MCC sub-handlers
(rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
rfcomm_recv_mcc). That fix and this one are complementary and
independent; neither subsumes the other.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
net/bluetooth/rfcomm/core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337..6b300237c 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1741,7 +1741,7 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
struct sk_buff *skb)
{
- struct rfcomm_hdr *hdr = (void *) skb->data;
+ struct rfcomm_hdr *hdr;
u8 type, dlci, fcs;
if (!s) {
@@ -1750,10 +1750,17 @@ static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
return s;
}
+ /* Minimum valid frame: addr(1) + ctrl(1) + len(1) + fcs(1) */
+ if (skb->len < sizeof(*hdr) + 1) {
+ kfree_skb(skb);
+ return s;
+ }
+
+ hdr = (void *) skb->data;
dlci = __get_dlci(hdr->addr);
type = __get_type(hdr->ctrl);
- /* Trim FCS */
+ /* Trim FCS - safe: skb->len >= sizeof(*hdr) + 1 >= 1 */
skb->len--; skb->tail--;
fcs = *(u8 *)skb_tail_pointer(skb);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: bnep: reject short frames before parsing
From: Cen Zhang @ 2026-05-19 2:39 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, zerocling0077,
2045gemini
In-Reply-To: <CABBYNZKC+Wr+0_aDUxpc2NmpfkM3_Gb7nvDxEChFPjdQZ0Dk-A@mail.gmail.com>
Hi Luiz,
Thanks for the review.
On Tue, May 19, 2026 at 05:39:00AM +0000, Luiz Augusto von Dentz wrote:
> Lets stop using skb->len directly and just skb_pull_data and theck if
> the return is NULL.
Sure, that makes sense. I will send a v3 using skb_pull_data() as
suggested.
Best regards,
Zhang Cen
^ permalink raw reply
* [Bug 220237] Bluetooth: MediaTek MT7925 (0e8d:7925) fails to load firmware with timeout (-110)
From: bugzilla-daemon @ 2026-05-19 2:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-220237-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=220237
Cameron VanHouzen (cameron@vanhouzen.me) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cameron@vanhouzen.me
--- Comment #5 from Cameron VanHouzen (cameron@vanhouzen.me) ---
Device: ASRock B850 Riptide WiFi
BIOS: 3.26 (2025-05-16)
OS: NixOS Unstable (rev d233902339c02a9c334e7e593de68855ad26c4cb)
Kernel: 6.12.89 (also tested 7.0.8)
WiFi/BT chip: MediaTek MT7925 RZ717 (PCIe ID: 14c3:0717, USB BT ID: 0e8d:0717)
I also am experiencing this issue, and have attempted all of the same
workarounds as Jens N. with no luck either.
dmesg output:
Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260106153314
Bluetooth: hci0: Execution of wmt command timed out
Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
Bluetooth: hci0: Failed to set up firmware (-110)
The BT device appears in lsusb as 0e8d:0717 and hci0 is created, but firmware
never loads. The device responds to the initial WMT version query but the BT
MCU version is always 0x00000000 and all subsequent
WMT patch download commands time out.
WiFi timeline from dmesg for reference in case it helps:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
20260106153120
mt7925e 0000:08:00.0 wlp8s0: renamed from wlan0
Firmware files present in /lib/firmware/mediatek/mt7925/:
BT_RAM_CODE_MT7925_1_1_hdr.bin
WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
WIFI_RAM_CODE_MT7925_1_1.bin
(linux-firmware version: 20260410)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [v2] Bluetooth: SMP: add missing skb len check in smp_cmd_keypress_notify
From: bluez.test.bot @ 2026-05-19 2:00 UTC (permalink / raw)
To: linux-bluetooth, meatuni001
In-Reply-To: <20260519001437.156400-1-meatuni001@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 936 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=1096915
---Test result---
Test Summary:
CheckPatch PASS 0.54 seconds
GitLint PASS 0.20 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.48 seconds
CheckAllWarning PASS 29.04 seconds
CheckSparse PASS 27.45 seconds
BuildKernel32 PASS 25.80 seconds
TestRunnerSetup PASS 568.32 seconds
TestRunner_smp-tester PASS 17.82 seconds
IncrementalBuild PASS 26.03 seconds
https://github.com/bluez/bluetooth-next/pull/212
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU
From: Michael Bommarito @ 2026-05-19 0:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Muhammad Bilal, linux-bluetooth, linux-kernel, marcel,
johan.hedberg
In-Reply-To: <CABBYNZLMEH8D+fZp_xfu665-E0QxNaefcVEsku5wnUQrxQjKBQ@mail.gmail.com>
On Mon, May 18, 2026 at 5:37 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
Two questions on this:
> > Implementations shall be able to handle the reception of multiple
> > commands in an L2CAP packet sent over fixed channel CID 0x0001.
> > [] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
> >
> > Perhaps we should define our Signalling MTU:
> >
> > Signaling MTU (MTUsig)
> ...
I went to add the constant in l2cap.h and noticed that our const names
don't quite align with the spec names. Do you want me to call this
MAX_MTU to be consistent with the const names or SIG_MTU to stick to
the standard?
> So we need to reject with L2CAP_REJ_MTU_EXCEEDED.
It looks like this would be our first use of L2CAP_REJ_MTU_EXCEEDED
anywhere, which seemed suspicious. Can you think of any other
locations offhand where we might want to check for an MTU guard?
Thanks,
Mike
^ permalink raw reply
* [PATCH v2] Bluetooth: SMP: add missing skb len check in smp_cmd_keypress_notify
From: Muhammad Bilal @ 2026-05-19 0:14 UTC (permalink / raw)
To: linux-bluetooth
Cc: linux-kernel, marcel, luiz.dentz, johan.hedberg, pmenzel, stable,
Muhammad Bilal
In-Reply-To: <20260517145417.31910-1-meatuni001@gmail.com>
smp_cmd_keypress_notify() accesses the received payload as
struct smp_cmd_keypress_notify without verifying that skb->len
contains enough data.
smp_sig_channel() removes the opcode byte before dispatching to
command handlers, so a SMP_CMD_KEYPRESS_NOTIFY packet without a
payload leaves skb->len equal to zero on entry to the handler,
causing a 1-byte out-of-bounds read from the heap.
Use skb_pull_data() to safely consume the payload; it performs
a bounds check internally and returns NULL when the packet is too
short. Add a ratelimited warning in that path to aid debugging
of malformed packets, matching the pattern used by hci_event.c.
Fixes: 1408bb6efb04 ("Bluetooth: Add dummy handler for LE SC keypress notification")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
net/bluetooth/smp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 98f1da4f5..1b237e623 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2930,7 +2930,15 @@ static int smp_cmd_dhkey_check(struct l2cap_conn *conn, struct sk_buff *skb)
static int smp_cmd_keypress_notify(struct l2cap_conn *conn,
struct sk_buff *skb)
{
- struct smp_cmd_keypress_notify *kp = (void *) skb->data;
+ struct smp_cmd_keypress_notify *kp;
+
+ kp = skb_pull_data(skb, sizeof(struct smp_cmd_keypress_notify));
+ if (!kp) {
+ bt_dev_warn_ratelimited(conn->hcon->hdev,
+ "Too small packet: skb->len %u < %zu",
+ skb->len, sizeof(struct smp_cmd_keypress_notify));
+ return SMP_INVALID_PARAMS;
+ }
bt_dev_dbg(conn->hcon->hdev, "value 0x%02x", kp->value);
--
2.54.0
^ permalink raw reply related
* Re: [GIT PULL] bluetooth 2026-05-14
From: patchwork-bot+netdevbpf @ 2026-05-18 23:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260514172340.1515042-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 14 May 2026 13:23:40 -0400 you wrote:
> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>
> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-05-14
https://git.kernel.org/netdev/net/c/23f3b04f157c
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 RESEND v4 1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Siwei Zhang @ 2026-05-18 23:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <CABBYNZL8zf+mfnLcs+X+9S2Kd=0-nSN6roywWk4wz=Bcmzqa4A@mail.gmail.com>
Hi Luiz,
On Mon, May 18, 2026, at 5:57 PM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Thu, May 14, 2026 at 8:23 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> Hi Luiz,
>>
>> On Mon, May 11, 2026, at 3:17 PM, Luiz Augusto von Dentz wrote:
>> > Hi,
>> >
>> > On Mon, May 11, 2026 at 1:09 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>> >>
>> >> l2cap_sock_new_connection_cb() accesses l2cap_pi(sk)->chan after
>> >> release_sock(parent). Once the parent lock is released, the child
>> >> socket sk can be freed by another task.
>> >>
>> >> Save the channel pointer into a local variable while the parent lock
>> >> is still held to prevent this.
>> >>
>> >> Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
>> >> Cc: stable@kernel.org
>> >> Assisted-by: Claude:claude-opus-4-7
>> >> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
>> >> ---
>> >> net/bluetooth/6lowpan.c | 5 +++++
>> >> net/bluetooth/l2cap_core.c | 12 ++++++++++++
>> >> net/bluetooth/l2cap_sock.c | 13 ++++++++++++-
>> >> net/bluetooth/smp.c | 5 +++++
>> >> 4 files changed, 34 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
>> >> index 23a229ab6a33..71c1c04b61e5 100644
>> >> --- a/net/bluetooth/6lowpan.c
>> >> +++ b/net/bluetooth/6lowpan.c
>> >> @@ -755,6 +755,11 @@ static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
>> >>
>> >> BT_DBG("chan %p pchan %p", chan, pchan);
>> >>
>> >> + /* Match the put that the caller of ops->new_connection() performs
>> >> + * once it is done with the returned channel pointer.
>> >> + */
>> >> + l2cap_chan_hold(chan);
>> >> +
>> >> return chan;
>> >> }
>> >>
>> >> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> >> index 7701528f1167..0f6c3c651207 100644
>> >> --- a/net/bluetooth/l2cap_core.c
>> >> +++ b/net/bluetooth/l2cap_core.c
>> >> @@ -4071,6 +4071,9 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
>> >>
>> >> __l2cap_chan_add(conn, chan);
>> >>
>> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
>> >> + l2cap_chan_put(chan);
>> >> +
>> >> dcid = chan->scid;
>> >>
>> >> __set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
>> >> @@ -4970,6 +4973,9 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
>> >>
>> >> __l2cap_chan_add(conn, chan);
>> >>
>> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
>> >> + l2cap_chan_put(chan);
>> >> +
>> >> l2cap_le_flowctl_init(chan, __le16_to_cpu(req->credits));
>> >>
>> >> dcid = chan->scid;
>> >> @@ -5194,6 +5200,9 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
>> >>
>> >> __l2cap_chan_add(conn, chan);
>> >>
>> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
>> >> + l2cap_chan_put(chan);
>> >> +
>> >> l2cap_ecred_init(chan, __le16_to_cpu(req->credits));
>> >>
>> >> /* Init response */
>> >> @@ -7407,6 +7416,9 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
>> >> chan->dst_type = dst_type;
>> >>
>> >> __l2cap_chan_add(conn, chan);
>> >> +
>> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
>> >> + l2cap_chan_put(chan);
>> >> }
>> >>
>> >> l2cap_chan_unlock(pchan);
>> >> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
>> >> index cf590a67d364..295c79cf5cf3 100644
>> >> --- a/net/bluetooth/l2cap_sock.c
>> >> +++ b/net/bluetooth/l2cap_sock.c
>> >> @@ -1497,6 +1497,7 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
>> >> static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
>> >> {
>> >> struct sock *sk, *parent = chan->data;
>> >> + struct l2cap_chan *child_chan;
>> >>
>> >> if (!parent)
>> >> return NULL;
>> >> @@ -1523,9 +1524,19 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
>> >>
>> >> bt_accept_enqueue(parent, sk, false);
>> >>
>> >> + child_chan = l2cap_pi(sk)->chan;
>> >> +
>> >> + /* Pin the channel for the caller. Once release_sock(parent) returns,
>> >> + * userspace can accept(2) and immediately close(2) the child socket,
>> >> + * which would drop the socket's references on the channel and free
>> >> + * it before the caller (e.g. l2cap_connect_req()) is done using the
>> >> + * returned pointer. The matching put is the caller's responsibility.
>> >> + */
>> >> + l2cap_chan_hold(child_chan);
>> >
>> > The entire problem might be solvable by not removing `list_add` from
>> > `l2cap_create_chan`. This way, it only allocates but does not attach
>> > to global_l until __l2cap_chan_add is called which then handles the
>> > addition.
>>
>> Could you please clarify what is "not removing `list_add` from
>> `l2cap_chan_create`"? I am not touching that part of code nor removing
>> the `list_add`. Do you want me to correspond the `chan` lifetime to `chan_list`?
>>
>> > Alternatively, we could allocate it first, given the
>> > circular dependency involving `l2cap_core`.c->l2cap_sock.c)
>> > new_connection -> l2cap_chan_create(l2cap_sock.c->l2cap_core.c) which
>>
>> This will change the signature of `l2cap_ops.new_connection`, which will be a large
>> refactoring across multiple files.
>>
>> Signature will be changed from
>> `struct l2cap_chan *(*new_connection) (struct l2cap_chan *chan);`
>> to
>> `void (*new_connection) (struct l2cap_chan *chan, struct l2cap_chan *new_chan)`
>> Do you want me to this in this patch or in the follow up patch?
>> If in this patch, I will drop the backport cc to stable.
>>
>> > makes the code rather hard to follow.
>> >
>>
>> I totally understand this will create a maintenance problem. I created this patch
>> mainly because it can be easily to be backported to the stable branches and it
>> is the safest fix (though ugly). I can send a follow up patch for this to refactor it
>> according to your suggestions.
>
> I don't think adding a new argument would be complicated. This
> argument could replace the current void return, and although it will
> affect a couple more places, it shouldn't be hard to backport if it
> really needs to be backported to begin with.
>
OK, I will do that.
Also, could you please check emails titled with
[PATCH v7] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()
I sent it to you privately with CC to security@kernel.org.
>>
>> >> release_sock(parent);
>> >>
>> >> - return l2cap_pi(sk)->chan;
>> >> + return child_chan;
>> >> }
>> >>
>> >> static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
>> >> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
>> >> index 1739c1989dbd..9796c3030434 100644
>> >> --- a/net/bluetooth/smp.c
>> >> +++ b/net/bluetooth/smp.c
>> >> @@ -3231,6 +3231,11 @@ static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
>> >>
>> >> BT_DBG("created chan %p", chan);
>> >>
>> >> + /* Match the put that the caller of ops->new_connection() performs
>> >> + * once it is done with the returned channel pointer.
>> >> + */
>> >> + l2cap_chan_hold(chan);
>> >> +
>> >> return chan;
>> >> }
>> >>
>> >> --
>> >> 2.54.0
>> >>
>> >
>> >
>> > --
>> > Luiz Augusto von Dentz
>>
>> Best,
>> Siwei
>
>
>
> --
> Luiz Augusto von Dentz
Best,
Siwei
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-18 22:56 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096012
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-18 22:56 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096354
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] e0f608: shared/rap: fix use of uninitialized value
From: BluezTestBot @ 2026-05-18 22:55 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: e0f608c05f9a007b9867c53234465f2b1fb0d8fa
https://github.com/bluez/bluez/commit/e0f608c05f9a007b9867c53234465f2b1fb0d8fa
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M src/shared/rap.c
Log Message:
-----------
shared/rap: fix use of uninitialized value
Fix error handling in send_ras_segment_data
Commit: dc07b3d54b801dea84e82397057071a824a38500
https://github.com/bluez/bluez/commit/dc07b3d54b801dea84e82397057071a824a38500
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M lib/bluetooth/sdp.c
Log Message:
-----------
sdp: Fix integer overflow in sdp_extract_seqtype
Check uint32_t value does not overflow int range.
Link: https://lore.kernel.org/linux-bluetooth/ygH6bncNsvf-0Hco92Ae11Lw8-jOfekFO6O3bUvFK8w0DTueny_rwJIF6ffZg2G_XCB4v8h8xRIcAL2b_KwaweNcGa231ZQDHCMpzyvR5i8=@fluentlogic.org/
Commit: 1e0688e8bfdaf20a34174dcd7ec855adb8e18216
https://github.com/bluez/bluez/commit/1e0688e8bfdaf20a34174dcd7ec855adb8e18216
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M src/main.conf
Log Message:
-----------
main.conf: fix unintentionally set value
Commit 31e4fb1498f ("monitor: Add decoding support for HIDS 1.1 flags
and attributes") unintentionally set a non-default value in main.conf.
Restore the value back.
Commit: 757cd98f4186e6e1e38b0a36539b78a20e93b5bf
https://github.com/bluez/bluez/commit/757cd98f4186e6e1e38b0a36539b78a20e93b5bf
Author: Zhao Dongdong <zhaodongdong@kylinos.cn>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M src/device.c
Log Message:
-----------
device: fix inverted NULL check in gatt_db clone
gatt_db_clone() returns NULL on failure so the condition was inverted.
With the old check a successful clone (non-NULL) would return false and
skip swapping the device's GATT database, while a failure (NULL) would
fall through and dereference a NULL pointer a few lines below.
Fix by negating the condition: only bail out early if the clone failed;
proceed with the swap when the clone actually succeeds.
Compare: https://github.com/bluez/bluez/compare/45e66b1c4aed...757cd98f4186
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] shared/rap: fix use of uninitialized value
From: patchwork-bot+bluetooth @ 2026-05-18 22:30 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <e7e72c0208f579fd6bb63b76f9d2a1ea3cabd2fc.1779013529.git.pav@iki.fi>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 17 May 2026 13:30:08 +0300 you wrote:
> Fix error handling in send_ras_segment_data
> ---
> src/shared/rap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Here is the summary with links:
- [BlueZ,1/3] shared/rap: fix use of uninitialized value
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e0f608c05f9a
- [BlueZ,2/3] sdp: Fix integer overflow in sdp_extract_seqtype
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=dc07b3d54b80
- [BlueZ,3/3] main.conf: fix unintentionally set value
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=1e0688e8bfda
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 v2] device: fix inverted NULL check in gatt_db clone
From: patchwork-bot+bluetooth @ 2026-05-18 22:30 UTC (permalink / raw)
To: Zhao Dongdong; +Cc: linux-bluetooth, zhaodongdong
In-Reply-To: <tencent_017770C54B37BDA20BEEC119272E1AED0608@qq.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 18 May 2026 14:45:32 +0800 you wrote:
> From: Zhao Dongdong <zhaodongdong@kylinos.cn>
>
> gatt_db_clone() returns NULL on failure so the condition was inverted.
> With the old check a successful clone (non-NULL) would return false and
> skip swapping the device's GATT database, while a failure (NULL) would
> fall through and dereference a NULL pointer a few lines below.
>
> [...]
Here is the summary with links:
- [BlueZ,v2] device: fix inverted NULL check in gatt_db clone
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=757cd98f4186
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 RESEND v4 1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Luiz Augusto von Dentz @ 2026-05-18 21:57 UTC (permalink / raw)
To: Siwei Zhang; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <558a354c-d2b6-4c7c-97cf-606753902b85@app.fastmail.com>
Hi Siwei,
On Thu, May 14, 2026 at 8:23 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> Hi Luiz,
>
> On Mon, May 11, 2026, at 3:17 PM, Luiz Augusto von Dentz wrote:
> > Hi,
> >
> > On Mon, May 11, 2026 at 1:09 PM Siwei Zhang <oss@fourdim.xyz> wrote:
> >>
> >> l2cap_sock_new_connection_cb() accesses l2cap_pi(sk)->chan after
> >> release_sock(parent). Once the parent lock is released, the child
> >> socket sk can be freed by another task.
> >>
> >> Save the channel pointer into a local variable while the parent lock
> >> is still held to prevent this.
> >>
> >> Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
> >> Cc: stable@kernel.org
> >> Assisted-by: Claude:claude-opus-4-7
> >> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> >> ---
> >> net/bluetooth/6lowpan.c | 5 +++++
> >> net/bluetooth/l2cap_core.c | 12 ++++++++++++
> >> net/bluetooth/l2cap_sock.c | 13 ++++++++++++-
> >> net/bluetooth/smp.c | 5 +++++
> >> 4 files changed, 34 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> >> index 23a229ab6a33..71c1c04b61e5 100644
> >> --- a/net/bluetooth/6lowpan.c
> >> +++ b/net/bluetooth/6lowpan.c
> >> @@ -755,6 +755,11 @@ static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
> >>
> >> BT_DBG("chan %p pchan %p", chan, pchan);
> >>
> >> + /* Match the put that the caller of ops->new_connection() performs
> >> + * once it is done with the returned channel pointer.
> >> + */
> >> + l2cap_chan_hold(chan);
> >> +
> >> return chan;
> >> }
> >>
> >> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> >> index 7701528f1167..0f6c3c651207 100644
> >> --- a/net/bluetooth/l2cap_core.c
> >> +++ b/net/bluetooth/l2cap_core.c
> >> @@ -4071,6 +4071,9 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
> >>
> >> __l2cap_chan_add(conn, chan);
> >>
> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
> >> + l2cap_chan_put(chan);
> >> +
> >> dcid = chan->scid;
> >>
> >> __set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
> >> @@ -4970,6 +4973,9 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> >>
> >> __l2cap_chan_add(conn, chan);
> >>
> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
> >> + l2cap_chan_put(chan);
> >> +
> >> l2cap_le_flowctl_init(chan, __le16_to_cpu(req->credits));
> >>
> >> dcid = chan->scid;
> >> @@ -5194,6 +5200,9 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
> >>
> >> __l2cap_chan_add(conn, chan);
> >>
> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
> >> + l2cap_chan_put(chan);
> >> +
> >> l2cap_ecred_init(chan, __le16_to_cpu(req->credits));
> >>
> >> /* Init response */
> >> @@ -7407,6 +7416,9 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
> >> chan->dst_type = dst_type;
> >>
> >> __l2cap_chan_add(conn, chan);
> >> +
> >> + /* Drop the ops->new_connection() ref; conn list now pins chan. */
> >> + l2cap_chan_put(chan);
> >> }
> >>
> >> l2cap_chan_unlock(pchan);
> >> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> >> index cf590a67d364..295c79cf5cf3 100644
> >> --- a/net/bluetooth/l2cap_sock.c
> >> +++ b/net/bluetooth/l2cap_sock.c
> >> @@ -1497,6 +1497,7 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
> >> static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> >> {
> >> struct sock *sk, *parent = chan->data;
> >> + struct l2cap_chan *child_chan;
> >>
> >> if (!parent)
> >> return NULL;
> >> @@ -1523,9 +1524,19 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> >>
> >> bt_accept_enqueue(parent, sk, false);
> >>
> >> + child_chan = l2cap_pi(sk)->chan;
> >> +
> >> + /* Pin the channel for the caller. Once release_sock(parent) returns,
> >> + * userspace can accept(2) and immediately close(2) the child socket,
> >> + * which would drop the socket's references on the channel and free
> >> + * it before the caller (e.g. l2cap_connect_req()) is done using the
> >> + * returned pointer. The matching put is the caller's responsibility.
> >> + */
> >> + l2cap_chan_hold(child_chan);
> >
> > The entire problem might be solvable by not removing `list_add` from
> > `l2cap_create_chan`. This way, it only allocates but does not attach
> > to global_l until __l2cap_chan_add is called which then handles the
> > addition.
>
> Could you please clarify what is "not removing `list_add` from
> `l2cap_chan_create`"? I am not touching that part of code nor removing
> the `list_add`. Do you want me to correspond the `chan` lifetime to `chan_list`?
>
> > Alternatively, we could allocate it first, given the
> > circular dependency involving `l2cap_core`.c->l2cap_sock.c)
> > new_connection -> l2cap_chan_create(l2cap_sock.c->l2cap_core.c) which
>
> This will change the signature of `l2cap_ops.new_connection`, which will be a large
> refactoring across multiple files.
>
> Signature will be changed from
> `struct l2cap_chan *(*new_connection) (struct l2cap_chan *chan);`
> to
> `void (*new_connection) (struct l2cap_chan *chan, struct l2cap_chan *new_chan)`
> Do you want me to this in this patch or in the follow up patch?
> If in this patch, I will drop the backport cc to stable.
>
> > makes the code rather hard to follow.
> >
>
> I totally understand this will create a maintenance problem. I created this patch
> mainly because it can be easily to be backported to the stable branches and it
> is the safest fix (though ugly). I can send a follow up patch for this to refactor it
> according to your suggestions.
I don't think adding a new argument would be complicated. This
argument could replace the current void return, and although it will
affect a couple more places, it shouldn't be hard to backport if it
really needs to be backported to begin with.
>
> >> release_sock(parent);
> >>
> >> - return l2cap_pi(sk)->chan;
> >> + return child_chan;
> >> }
> >>
> >> static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> >> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> >> index 1739c1989dbd..9796c3030434 100644
> >> --- a/net/bluetooth/smp.c
> >> +++ b/net/bluetooth/smp.c
> >> @@ -3231,6 +3231,11 @@ static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
> >>
> >> BT_DBG("created chan %p", chan);
> >>
> >> + /* Match the put that the caller of ops->new_connection() performs
> >> + * once it is done with the returned channel pointer.
> >> + */
> >> + l2cap_chan_hold(chan);
> >> +
> >> return chan;
> >> }
> >>
> >> --
> >> 2.54.0
> >>
> >
> >
> > --
> > Luiz Augusto von Dentz
>
> Best,
> Siwei
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: MGMT: validate Add Extended Advertising Data length
From: patchwork-bot+bluetooth @ 2026-05-18 21:50 UTC (permalink / raw)
To: Michael Bommarito
Cc: marcel, luiz.dentz, danielwinkler, linux-bluetooth, linux-kernel
In-Reply-To: <20260515143819.1157807-1-michael.bommarito@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Fri, 15 May 2026 10:38:19 -0400 you wrote:
> MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,
> with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler
> then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy
> cp->data, but it never checks that those bytes are part of the mgmt
> command payload.
>
> A short command can therefore make add_ext_adv_data() pass an
> out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond
> the command buffer are addressable, they can also be copied into the
> advertising instance as scan response data, where the caller can read
> them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires
> CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte
> slab-out-of-bounds read.
>
> [...]
Here is the summary with links:
- Bluetooth: MGMT: validate Add Extended Advertising Data length
https://git.kernel.org/bluetooth/bluetooth-next/c/8f5b6b4b198e
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: fix urb->setup_packet leak in error paths
From: patchwork-bot+bluetooth @ 2026-05-18 21:50 UTC (permalink / raw)
To: Jiajia Liu
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
sean.wang, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260518022402.20398-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 Mon, 18 May 2026 10:24:02 +0800 you wrote:
> The setup_packet of control urb is not freed if usb_submit_urb fails or
> the submitted urb is killed. Add free in these two paths.
>
> Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/bluetooth/btmtk.c | 2 ++
> 1 file changed, 2 insertions(+)
Here is the summary with links:
- Bluetooth: btmtk: fix urb->setup_packet leak in error paths
https://git.kernel.org/bluetooth/bluetooth-next/c/5daf96ab8398
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [v2] Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
From: bluez.test.bot @ 2026-05-18 21:45 UTC (permalink / raw)
To: linux-bluetooth, jarys.cz
In-Reply-To: <20260518210335.1105068-1-jarys.cz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 882 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=1096857
---Test result---
Test Summary:
CheckPatch PASS 0.73 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.13 seconds
CheckAllWarning PASS 27.49 seconds
CheckSparse PASS 26.45 seconds
BuildKernel32 PASS 24.51 seconds
TestRunnerSetup PASS 520.86 seconds
IncrementalBuild PASS 24.00 seconds
https://github.com/bluez/bluetooth-next/pull/211
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: bnep: reject short frames before parsing
From: Luiz Augusto von Dentz @ 2026-05-18 21:39 UTC (permalink / raw)
To: Zhang Cen
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, zerocling0077,
2045gemini
In-Reply-To: <20260516004433.3199522-1-rollkingzzc@gmail.com>
Hi,
On Fri, May 15, 2026 at 8:44 PM Zhang Cen <rollkingzzc@gmail.com> wrote:
>
> An L2CAP peer can deliver an empty BNEP payload or a payload that contains
> only the outer type byte. bnep_rx_frame() currently reads the BNEP type
> byte and, for control packets, the control opcode before it proves that
> the skb contains those bytes. The BNEP_SETUP_CONN_REQ path can also read
> the setup size byte before that byte is present, and bnep_rx_control()
> dereferences the control opcode before checking that its control payload
> is non-empty.
>
> Reject empty skbs before reading the outer type byte, require a control
> opcode before parsing BNEP_CONTROL, require the setup size byte before
> using it, and make bnep_rx_control() fail zero-length control payloads.
>
> Validation reproduced this kernel report:
> KASAN slab-out-of-bounds in bnep_rx_frame()
> Read of size 1
> Call trace:
> dump_stack_lvl() (?:?)
> print_address_description() (mm/kasan/report.c:373)
> bnep_rx_frame() (net/bluetooth/bnep/core.c:306)
> print_report() (?:?)
> __virt_addr_valid() (?:?)
> srso_alias_return_thunk() (arch/x86/include/asm/nospec-branch.h:375)
> kasan_addr_to_slab() (mm/kasan/common.c:45)
> kasan_report() (?:?)
> process_one_work() (kernel/workqueue.c:3200)
> worker_thread() (?:?)
> __kthread_parkme() (kernel/kthread.c:259)
> kthread() (?:?)
> _raw_spin_unlock_irq() (kernel/locking/spinlock.c:204)
> ret_from_fork() (?:?)
> __switch_to() (?:?)
> ret_from_fork_asm() (?:?)
> kasan_save_stack() (mm/kasan/common.c:52)
> kasan_save_track() (mm/kasan/common.c:74)
> __kasan_kmalloc() (?:?)
> vpanic() (kernel/panic.c:576)
> panic() (?:?)
> preempt_schedule_common() (kernel/sched/core.c:7352)
> preempt_schedule_thunk() (?:?)
> end_report() (mm/kasan/report.c:219)
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
>
> ---
> diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
> index d44987d4515c..f5070bbd6b57 100644
> --- a/net/bluetooth/bnep/core.c
> +++ b/net/bluetooth/bnep/core.c
> @@ -208,9 +208,14 @@ static int bnep_ctrl_set_mcfilter(struct bnep_session *s, u8 *data, int len)
>
> static int bnep_rx_control(struct bnep_session *s, void *data, int len)
> {
> - u8 cmd = *(u8 *)data;
> + u8 cmd;
> int err = 0;
>
> + if (len < 1)
> + return -EILSEQ;
> +
> + cmd = *(u8 *)data;
> +
> data++;
> len--;
>
> @@ -303,14 +308,21 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
>
> dev->stats.rx_bytes += skb->len;
>
> + if (skb->len < 1)
> + goto badframe;
Lets stop using skb->len directly and just skb_pull_data and theck if
the return is NULL.
> type = *(u8 *) skb->data;
> skb_pull(skb, 1);
> - ctrl_type = *(u8 *)skb->data;
>
> if ((type & BNEP_TYPE_MASK) >= sizeof(__bnep_rx_hlen))
> goto badframe;
>
> if ((type & BNEP_TYPE_MASK) == BNEP_CONTROL) {
> + if (skb->len < 1)
> + goto badframe;
> +
> + ctrl_type = *(u8 *)skb->data;
> +
> if (bnep_rx_control(s, skb->data, skb->len) < 0) {
> dev->stats.tx_errors++;
> kfree_skb(skb);
> @@ -326,6 +338,9 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
> switch (ctrl_type) {
> case BNEP_SETUP_CONN_REQ:
> /* Pull: ctrl type (1 b), len (1 b), data (len bytes) */
> + if (skb->len < 2)
> + goto badframe;
> +
> if (!skb_pull(skb, 2 + *(u8 *)(skb->data + 1) * 2))
> goto badframe;
> break;
--
Luiz Augusto von Dentz
^ 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