* [Bug 221552] New: btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920) Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-19 17:29 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221552
Bug ID: 221552
Summary: btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920)
Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does
not cover this PID
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: gagnieux.virgil@proton.me
Regression: No
Created attachment 310159
--> https://bugzilla.kernel.org/attachment.cgi?id=310159&action=edit
dmesg kernel (from 7.0.9-hardened1-1-hardened)
Regression: Bluetooth controller fails to initialise on a MediaTek MT7921
(Legion Pro 5 16ADR10, Realtek-branded module) since kernel 7.0.7.
Last known good: 7.0.6. Same dmesg symptom as the regression already
patched for USB ID 0489:e0e2, but the fix does NOT resolve it for this
device (USB 0e8d:e020), which suggests the patch missed a code path or
device-ID entry.
Hardware
--------
lspci -nnk:
03:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7920]
DeviceName: Realtek
Subsystem: Lenovo Device [17aa:e020]
Kernel driver in use: mt7921e
lsusb:
Bus 003 Device 006: ID 0e8d:e020 MediaTek Inc. Wireless_Device
Kernels tested
--------------
7.0.6 : Bluetooth works
7.0.8 / 7.0.9 (mainline) : broken
7.0.9-hardened1-1 : broken (linux-hardened — current)
This build includes the backport
https://github.com/anthraxx/linux-hardened/commit/<…81d80fcd09>
which adds the fix for USB ID 0489:e0e2. It does NOT fix 0e8d:e020.
uname -r : 7.0.9-hardened1-1-hardened
dmesg (from kernel 7.0.9, relevant lines)
-----------------------------------------
[ 23.898011] Bluetooth: Core ver 2.22
[ 23.898032] NET: Registered PF_BLUETOOTH protocol family
[ 23.898033] Bluetooth: HCI device and connection manager initialized
[ 23.898041] Bluetooth: HCI socket layer initialized
[ 23.898043] Bluetooth: L2CAP socket layer initialized
[ 23.898045] Bluetooth: SCO socket layer initialized
[ 24.800153] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time:
20260224111231
[ 24.922472] Bluetooth: hci0: Failed to send wmt func ctrl (-22)
[ 24.922477] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection
command is advertised, but not supported.
[ 25.517793] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 25.517796] Bluetooth: BNEP filters: protocol multicast
[ 25.517800] Bluetooth: BNEP socket layer initialized
Userspace state
---------------
bluetoothctl list → (no output)
bluetoothctl show → No default controller available
Module
------
modinfo btmtk:
filename:
/lib/modules/7.0.9-hardened1-1-hardened/kernel/drivers/bluetooth/btmtk.ko.zst
firmware: mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
firmware: mediatek/mt7668pr2h.bin
Versions (Arch Linux)
---------------------
linux-firmware : 20260410-1
linux-firmware-mediatek : 20260410-1
bluez : 5.86-6
Steps to reproduce
------------------
1. Boot kernel >= 7.0.7 on a system with MediaTek 14c3:7920 / USB 0e8d:e020.
2. Bluetooth controller fails to initialise; -EINVAL (-22) on wmt func ctrl.
Expected
--------
Controller comes up, same as on 7.0.6.
Related
-------
- Arch forum thread: https://bbs.archlinux.org/viewtopic.php?id=313552
- Same symptom, different PID 0489:e0d8:
https://bbs.archlinux.org/viewtopic.php?id=313561
- Existing fix that targets 0489:e0e2 only:
https://github.com/anthraxx/linux-hardened/commit/d019930b0049fc2648a6b279893d8ad330596e81
(does not cover USB ID 0e8d:e020 — a second device-ID / code-path entry
appears to be needed)
I can test patches.
--
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
* [Bug 221551] btmtk: MT7921 (USB ID 0e8d:e020) Bluetooth broken since 7.0.7 — fix commit for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-19 17:23 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221551-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221551
Virgil GAGNIEUX (gagnieux.virgil@proton.me) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE
--
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
* [Bug 221551] btmtk: MT7921 (USB ID 0e8d:e020) Bluetooth broken since 7.0.7 — fix commit for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-19 17:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221551-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221551
Virgil GAGNIEUX (gagnieux.virgil@proton.me) changed:
What |Removed |Added
----------------------------------------------------------------------------
Kernel Version| |7.0.9-hardened1-1-hardened
--
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
* [Bug 221551] New: btmtk: MT7921 (USB ID 0e8d:e020) Bluetooth broken since 7.0.7 — fix commit for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-19 17:21 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221551
Bug ID: 221551
Summary: btmtk: MT7921 (USB ID 0e8d:e020) Bluetooth broken
since 7.0.7 — fix commit for 0489:e0e2 does not cover
this PID
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: gagnieux.virgil@proton.me
Regression: No
Created attachment 310158
--> https://bugzilla.kernel.org/attachment.cgi?id=310158&action=edit
dmesg (from kernel 7.0.9, relevant lines)
Regression: Bluetooth controller stops initialising on a MediaTek MT7921
since kernel 7.0.7. Last known good: 7.0.6.
Same symptom as the regression already discussed and patched for USB ID
0489:e0e2, but the fix does NOT resolve it for my device (0e8d:e020),
which suggests the patch missed a code path / device ID.
Hardware
--------
lspci: 03:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7920]
Kernel driver in use: mt7921e
lsusb: Bus 003 Device 006: ID 0e8d:e020 MediaTek Inc. Wireless_Device
Kernels tested
--------------
7.0.6 : Bluetooth works
7.0.8 / 7.0.9 : broken (mainline Arch build, please confirm if you also
tested it)
7.0.9-hardened1-1 : broken (linux-hardened, includes the backport
https://github.com/anthraxx/linux-hardened/commit/<…81d80fcd09>
which targets 0489:e0e2 — it does NOT fix 0e8d:e020)
dmesg (relevant lines)
----------------------
[ 24.800153] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time:
20260224111231
[ 24.922472] Bluetooth: hci0: Failed to send wmt func ctrl (-22)
[ 24.922477] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection
command is advertised, but not supported.
Userspace state
---------------
bluetoothctl list → (no output)
bluetoothctl show → No default controller available
rfkill → hci0 not present / soft blocked depending on boot
Versions
--------
bluez : <colle ta version>
linux-firmware : <…>
linux-firmware-mediatek : <…>
Steps to reproduce
------------------
1. Boot kernel >= 7.0.7 on a system with MediaTek 14c3:7920 / USB 0e8d:e020
2. Bluetooth controller fails to initialise; -EINVAL on wmt func ctrl
Expected
--------
Controller comes up, same as on 7.0.6.
Related
-------
- Arch forum thread: https://bbs.archlinux.org/viewtopic.php?id=313552
- Related thread (same symptom, different PID 0489:e0d8):
https://bbs.archlinux.org/viewtopic.php?id=313561
- Fix that addresses 0489:e0e2 only:
https://github.com/anthraxx/linux-hardened/commit/<…81d80fcd09>
Please note: the existing fix above is referenced because it explicitly
does NOT cover USB ID 0e8d:e020. A second code path / device-ID entry
seems to be needed.
I can test patches.
--
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: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU
From: Luiz Augusto von Dentz @ 2026-05-19 16:02 UTC (permalink / raw)
To: Michael Bommarito
Cc: Muhammad Bilal, linux-bluetooth, linux-kernel, marcel,
johan.hedberg
In-Reply-To: <CAJJ9bXxVeO6a-gi+7B_FV0tciZA5-iLt1600=Fmweh850EZg8A@mail.gmail.com>
Hi Michael,
On Mon, May 18, 2026 at 8:43 PM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> 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?
I guess L2CAP_SIG_MTU is fine.
>
> > 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?
This is our first use. I don't think this error existed initially; it
was probably added to handle cases where signalling channels need to
indicate their MTU.
> Thanks,
> Mike
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Luiz Augusto von Dentz @ 2026-05-19 15:49 UTC (permalink / raw)
To: Greg KH
Cc: Thorsten Leemhuis, stable@vger.kernel.org, Sasha Levin,
linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <2026051942-uproar-drainpipe-6370@gregkh>
Hi Greg,
On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> >
> > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > >>>
> > > > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > >>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > >>>>
> > > > >>>> are available in the Git repository at:
> > > > >>>>
> > > > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > >>>>
> > > > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > >>>>
> > > > >>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > >>>
> > > > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > > > >>> that was merged yesterday.
> > > > >>>
> > > > >>> TWIMC, from my point of view, it would be great if we somehow could
> > > > >>> still get the changes from this PR or at least the btmtk fix it
> > > > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > > > >>> regression known since 2026-04-24 that at least five people encountered
> > > > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > > > >>> -next].
> > > > >>
> > > > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > >> events") and will likely hit mainline on Thursday or so with the weekly
> > > > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > >> good to pick this up for the next round of stable kernels.
> > > > >
> > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > > of these:
> > > >
> > > > Valid question, as yes, there is a slight mixup here:
> > > >
> > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > >
> > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > that is causing the regression that I want to get fixed. So we now only
> > > > need:
> > > >
> > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > >
> > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > nightmare to track over time, ugh.
> >
> > Hmm, did we get the wrong hash or something? Usually, that would show
> > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > for some reason, perhaps I'm running an outdated version or something
> > similar.
>
> Something went wrong if we ended up with a patch in the stable trees,
> yet this fix is referring to it as a different git sha. Don't know
> where the disconnect happend :(
041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
struct access")
I don't have that in any of our tree either, this is actually
634a4408c061 on all trees in the chain:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
Or actually that was the hash before it got rebased on bluetooth-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
But I didn't send the PR from that three so perhaps somebody else sent
it to stable with the wrong fixes tag?
> thanks,
>
> greg k-h
--
Luiz Augusto von Dentz
^ permalink raw reply
* [RFC PATCH] Bluetooth: btusb: wait for rx_work before freeing data on disconnect
From: Philipp Weber @ 2026-05-19 15:44 UTC (permalink / raw)
To: marcel, luiz.dentz
Cc: linux-bluetooth, linux-kernel, syzkaller-bugs,
syzbot+d06554f43a8fb48030b0
In-Reply-To: <6a0c3fc4.a00a0220.2ee31e.0002.GAE@google.com>
syzbot reports a slab-use-after-free in skb_dequeue() called from
btusb_rx_work(), with the freed object being the btusb_data struct
released by btusb_disconnect() via usb_unbind_interface() -> kfree().
The race:
btusb_close() (via hci_unregister_dev -> hdev->close)
cancel_delayed_work(&data->rx_work); <-- non-sync
...
btusb_stop_traffic(data); <-- kills URBs
A URB completion callback fired between the non-sync cancel and
btusb_stop_traffic() can call data->recv_acl() -> hci_recv_frame(),
which enqueues to data->acl_q and schedules data->rx_work again.
The cancel above already returned, so the newly-scheduled rx_work
is left pending. btusb_disconnect() then proceeds to kfree(data)
while rx_work may still execute, dereferencing data->acl_q in
skb_dequeue().
Drain rx_work in btusb_disconnect() before kfree(data). At that
point hci_unregister_dev() has fully returned, btusb_close() has
already killed all URBs via btusb_stop_traffic(), so no new
scheduling can happen. Any rx_work item that was re-scheduled by a
late URB callback in the close path is guaranteed to be drained.
This runs without hci_req_sync_lock held (it was acquired by
hci_dev_do_close and released before btusb_disconnect resumes), so
the sync cancel has no deadlock interaction with the close path.
Fixes: 800fe5ec302e ("Bluetooth: btusb: Add support for queuing during polling interval")
Reported-by: syzbot+d06554f43a8fb48030b0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d06554f43a8fb48030b0
Signed-off-by: Philipp Weber <kernel@phwe.de>
---
drivers/bluetooth/btusb.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7f5fce93d984..5d4ea44cd3c9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -4462,6 +4462,15 @@ static void btusb_disconnect(struct usb_interface *intf)
usb_driver_release_interface(&btusb_driver, data->intf);
}
+ /*
+ * rx_work is scheduled from URB completion handlers; btusb_close()
+ * (called via hci_unregister_dev) uses a non-sync cancel, so a work
+ * item may still be queued or executing when we reach this point.
+ * Wait for it before freeing data, otherwise the worker dereferences
+ * freed memory through skb_dequeue(&data->acl_q).
+ */
+ cancel_delayed_work_sync(&data->rx_work);
+
hci_free_dev(hdev);
kfree(data);
}
base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] bluetooth 2026-05-14
From: Greg KH @ 2026-05-19 15:18 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Thorsten Leemhuis, stable@vger.kernel.org, Sasha Levin,
linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <CABBYNZKKbTXc-okp9P2OncMYXHX9C1XC+pRC7XWOhv-8nPNZ5A@mail.gmail.com>
On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> Hi Greg,
>
> On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > On 5/19/26 12:30, Greg KH wrote:
> > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > >>>
> > > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > >>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > >>>>
> > > >>>> are available in the Git repository at:
> > > >>>>
> > > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > >>>>
> > > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > >>>>
> > > >>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > >>>
> > > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > > >>> that was merged yesterday.
> > > >>>
> > > >>> TWIMC, from my point of view, it would be great if we somehow could
> > > >>> still get the changes from this PR or at least the btmtk fix it
> > > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > > >>> regression known since 2026-04-24 that at least five people encountered
> > > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > > >>> -next].
> > > >>
> > > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > >> events") and will likely hit mainline on Thursday or so with the weekly
> > > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > >> good to pick this up for the next round of stable kernels.
> > > >
> > > > That "Fixes:" tag is referring to something that is also not in any
> > > > tree, but that commit does have a cc: stable in it. So do we need both
> > > > of these:
> > >
> > > Valid question, as yes, there is a slight mixup here:
> > >
> > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > >
> > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > that is causing the regression that I want to get fixed. So we now only
> > > need:
> > >
> > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> >
> > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > nightmare to track over time, ugh.
>
> Hmm, did we get the wrong hash or something? Usually, that would show
> up in the verify-fixes.sh, but perhaps it didn't capture it this time
> for some reason, perhaps I'm running an outdated version or something
> similar.
Something went wrong if we ended up with a patch in the stable trees,
yet this fix is referring to it as a different git sha. Don't know
where the disconnect happend :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v9] Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
From: patchwork-bot+bluetooth @ 2026-05-19 15:00 UTC (permalink / raw)
To: w15303746062
Cc: luiz.dentz, pmenzel, marcel, linux-bluetooth, linux-serial,
linux-kernel, greg, stable, 25181214217
In-Reply-To: <20260518024949.439299-1-w15303746062@163.com>
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:49:49 +0800 you wrote:
> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
> Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer
> Dereference (NPD) conditions were observed in the lifecycle management
> of hci_uart.
>
> The primary issue arises because the workqueues (init_ready and
> write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY
> flag is set during TTY close. If a hangup occurs before setup completes,
> hci_uart_tty_close() skips the teardown of these workqueues and
> proceeds to free the `hu` struct. When the scheduled work executes
> later, it blindly dereferences the freed `hu` struct.
>
> [...]
Here is the summary with links:
- [v9] Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
https://git.kernel.org/bluetooth/bluetooth-next/c/7db62a762f61
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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 14:52 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
--- Comment #12 from Artem S. Tashkinov (aros@gmx.com) ---
The patch has landed in 7.0.10. Hooray.
--
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: [PATCH] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Luiz Augusto von Dentz @ 2026-05-19 13:51 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, netdev, linux-kernel, Marcel Holtmann, Kees Cook,
Jakub Kicinski
In-Reply-To: <20260519042017.29564-1-meatuni001@gmail.com>
Hi Muhammad,
On Tue, May 19, 2026 at 12:20 AM Muhammad Bilal <meatuni001@gmail.com> wrote:
>
> 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;
Let's replace this with skb_pull_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--;
It might be a good idea to check if we can use skb_pull_data here as
well, instead of changing the tail to then use skb_tail_pointer.
> fcs = *(u8 *)skb_tail_pointer(skb);
>
> --
> 2.54.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Luiz Augusto von Dentz @ 2026-05-19 13:44 UTC (permalink / raw)
To: Greg KH
Cc: Thorsten Leemhuis, stable@vger.kernel.org, Sasha Levin,
linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <2026051909-impurity-nemesis-2f65@gregkh>
Hi Greg,
On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > On 5/19/26 12:30, Greg KH wrote:
> > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > >>>
> > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > >>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > >>>>
> > >>>> are available in the Git repository at:
> > >>>>
> > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > >>>>
> > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > >>>>
> > >>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > >>>
> > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > >>> that was merged yesterday.
> > >>>
> > >>> TWIMC, from my point of view, it would be great if we somehow could
> > >>> still get the changes from this PR or at least the btmtk fix it
> > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > >>> regression known since 2026-04-24 that at least five people encountered
> > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > >>> -next].
> > >>
> > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > >> events") and will likely hit mainline on Thursday or so with the weekly
> > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > >> good to pick this up for the next round of stable kernels.
> > >
> > > That "Fixes:" tag is referring to something that is also not in any
> > > tree, but that commit does have a cc: stable in it. So do we need both
> > > of these:
> >
> > Valid question, as yes, there is a slight mixup here:
> >
> > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> >
> > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > btmtk: validate WMT event SKB length before struct access") -- the one
> > that is causing the regression that I want to get fixed. So we now only
> > need:
> >
> > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
>
> Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> nightmare to track over time, ugh.
Hmm, did we get the wrong hash or something? Usually, that would show
up in the verify-fixes.sh, but perhaps it didn't capture it this time
for some reason, perhaps I'm running an outdated version or something
similar.
I will try making the Bluetooth CI run the verify-fixes.sh to detect
this sort of issue early on.
> I'll go queue this up now, thanks.
>
> greg k-h
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: Fixes/improvements for the PCI M.2 power sequencing driver
From: bluez.test.bot @ 2026-05-19 13:16 UTC (permalink / raw)
To: linux-bluetooth, manivannan.sadhasivam
In-Reply-To: <20260519-pwrseq-m2-bt-v3-1-b39dc2ae3966@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 4895 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=1097194
---Test result---
Test Summary:
CheckPatch PASS 5.38 seconds
GitLint FAIL 2.04 seconds
SubjectPrefix FAIL 0.68 seconds
BuildKernel PASS 27.13 seconds
CheckAllWarning PASS 29.85 seconds
CheckSparse PASS 28.89 seconds
BuildKernel32 PASS 26.11 seconds
TestRunnerSetup PASS 577.16 seconds
TestRunner_l2cap-tester PASS 378.64 seconds
TestRunner_iso-tester PASS 597.42 seconds
TestRunner_bnep-tester PASS 18.52 seconds
TestRunner_mgmt-tester PASS 2022.79 seconds
TestRunner_rfcomm-tester PASS 63.23 seconds
TestRunner_sco-tester PASS 141.44 seconds
TestRunner_ioctl-tester PASS 133.59 seconds
TestRunner_mesh-tester PASS 60.51 seconds
TestRunner_smp-tester PASS 18.42 seconds
TestRunner_userchan-tester PASS 20.59 seconds
TestRunner_6lowpan-tester PASS 51.38 seconds
IncrementalBuild PASS 38.82 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3,2/9] power: sequencing: pcie-m2: Allow creating serdev for multiple PCI devices
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
1: T1 Title exceeds max length (83>80): "[v3,2/9] power: sequencing: pcie-m2: Allow creating serdev for multiple PCI devices"
[v3,4/9] power: sequencing: pcie-m2: Create serdev for PCI devices present before probe
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
1: T1 Title exceeds max length (87>80): "[v3,4/9] power: sequencing: pcie-m2: Create serdev for PCI devices present before probe"
[v3,5/9] power: sequencing: pcie-m2: Create BT node based on the pci_device_id[] table
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
1: T1 Title exceeds max length (86>80): "[v3,5/9] power: sequencing: pcie-m2: Create BT node based on the pci_device_id[] table"
[v3,6/9] power: sequencing: Add an API to return the pwrseq device's 'dev' pointer
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
1: T1 Title exceeds max length (82>80): "[v3,6/9] power: sequencing: Add an API to return the pwrseq device's 'dev' pointer"
[v3,9/9] Bluetooth: hci_qca: Set 'bt_en_available' based on W_DISABLE2# presence in M.2 connector
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
1: T1 Title exceeds max length (97>80): "[v3,9/9] Bluetooth: hci_qca: Set 'bt_en_available' based on W_DISABLE2# presence in M.2 connector"
##############################
Test: SubjectPrefix - FAIL
Desc: Check subject contains "Bluetooth" prefix
Output:
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
https://github.com/bluez/bluetooth-next/pull/215
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221547] MT7902 Bluetooth: Failed to send wmt func ctrl (-22) regression in 6.18.31 and 6.12.32
From: bugzilla-daemon @ 2026-05-19 12:55 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221547-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221547
--- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
Please check if this patch fixes it:
https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
--
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: client/btpclient: Add GAP extended advertising support
From: bluez.test.bot @ 2026-05-19 12:34 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
In-Reply-To: <20260519105519.226648-2-frederic.danis@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 2213 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=1097304
---Test result---
Test Summary:
CheckPatch FAIL 1.19 seconds
GitLint PASS 0.75 seconds
BuildEll PASS 21.12 seconds
BluezMake PASS 625.35 seconds
CheckSmatch WARNING 326.82 seconds
bluezmakeextell PASS 164.98 seconds
IncrementalBuild PASS 636.73 seconds
ScanBuild PASS 930.69 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,1/3] client/btpclient: refactor read-commands bitmap building
WARNING:BAD_SIGN_OFF: Non-standard signature: Assisted-by:
#84:
Assisted-by: GPT:GPT-5.3-Codex
ERROR:BAD_SIGN_OFF: Unrecognized email address: 'GPT:GPT-5.3-Codex'
#84:
Assisted-by: GPT:GPT-5.3-Codex
/github/workspace/src/patch/14581674.patch total: 1 errors, 1 warnings, 255 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/14581674.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
client/btpclient/gatt.c: note: in included file:./src/shared/btp.h:335:41: warning: array of flexible structures./src/shared/btp.h:340:55: warning: array of flexible structures./src/shared/btp.h:363:47: warning: array of flexible structures./src/shared/btp.h:392:42: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2137
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v2,1/2] client/btpclient: Fix GAP unpair command
From: bluez.test.bot @ 2026-05-19 12:23 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
In-Reply-To: <20260519085016.188744-1-frederic.danis@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 825 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=1097183
---Test result---
Test Summary:
CheckPatch PASS 0.68 seconds
GitLint PASS 0.44 seconds
BuildEll PASS 20.92 seconds
BluezMake PASS 495.39 seconds
CheckSmatch PASS 250.90 seconds
bluezmakeextell PASS 127.61 seconds
IncrementalBuild PASS 498.62 seconds
ScanBuild PASS 709.32 seconds
https://github.com/bluez/bluez/pull/2136
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v3] Bluetooth: bnep: reject short frames before parsing
From: bluez.test.bot @ 2026-05-19 12:16 UTC (permalink / raw)
To: linux-bluetooth, rollkingzzc
In-Reply-To: <20260519113943.3656062-1-rollkingzzc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1607 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=1097332
---Test result---
Test Summary:
CheckPatch PASS 0.77 seconds
GitLint FAIL 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.40 seconds
CheckAllWarning PASS 27.62 seconds
CheckSparse PASS 26.64 seconds
BuildKernel32 PASS 24.54 seconds
TestRunnerSetup PASS 530.16 seconds
TestRunner_bnep-tester PASS 18.87 seconds
IncrementalBuild PASS 24.16 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: bnep: reject short frames before parsing
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
42: B1 Line exceeds max length (123>80): "Use skb_pull_data() with NULL checks in bnep_rx_frame() instead of direct skb->len guards before fixed header dereferences."
https://github.com/bluez/bluetooth-next/pull/216
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Greg KH @ 2026-05-19 12:06 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: stable@vger.kernel.org, Sasha Levin, linux-bluetooth, netdev,
Luiz Augusto von Dentz, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <eb5301f9-3133-4fe3-b358-61f14d1ffa5b@leemhuis.info>
On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> On 5/19/26 12:30, Greg KH wrote:
> > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> >>>
> >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> >>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> >>>>
> >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> >>>>
> >>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> >>>
> >>> It seems this PR sadly came too late for this week's net PR to mainline
> >>> that was merged yesterday.
> >>>
> >>> TWIMC, from my point of view, it would be great if we somehow could
> >>> still get the changes from this PR or at least the btmtk fix it
> >>> contains[1] to mainline this week before -rc4, as it is fixing a
> >>> regression known since 2026-04-24 that at least five people encountered
> >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> >>> validate WMT event SKB length before struct access") [006b9943b982 in
> >>> -next].
> >>
> >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> >> events") and will likely hit mainline on Thursday or so with the weekly
> >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> >> good to pick this up for the next round of stable kernels.
> >
> > That "Fixes:" tag is referring to something that is also not in any
> > tree, but that commit does have a cc: stable in it. So do we need both
> > of these:
>
> Valid question, as yes, there is a slight mixup here:
>
> > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
>
> That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> btmtk: validate WMT event SKB length before struct access") -- the one
> that is causing the regression that I want to get fixed. So we now only
> need:
>
> > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
nightmare to track over time, ugh.
I'll go queue this up now, thanks.
greg k-h
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-19 11:48 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1097130
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] 0cb83c: client/btpclient: refactor read-commands bitmap bu...
From: fdanis-oss @ 2026-05-19 11:48 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1097304
Home: https://github.com/bluez/bluez
Commit: 0cb83cdaeb54b3c4b0f544f3b5689ce52974988f
https://github.com/bluez/bluez/commit/0cb83cdaeb54b3c4b0f544f3b5689ce52974988f
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/bap.c
M client/btpclient/btpclient.c
M client/btpclient/btpclient.h
M client/btpclient/core.c
M client/btpclient/gap.c
M client/btpclient/gatt.c
Log Message:
-----------
client/btpclient: refactor read-commands bitmap building
Add add_supported_command() and use it across all btp_*_read_commands
handlers.
This replaces fixed-size bitmask assembly with a dynamically growing
command bitmap based on opcode index, avoiding shift-width issues with
higher opcodes.
This will allow to add opcodes like GAP_SET_EXTENDED_ADVERTISING
(0x21).
Refactor core, gap, gatt and bap read-commands paths to build response
bitmaps through the shared helper and preserve existing error handling
for allocation failures.
Assisted-by: GPT:GPT-5.3-Codex
Commit: 654df3d8b47612d2d0d740d940095982c8f9d9e9
https://github.com/bluez/bluez/commit/654df3d8b47612d2d0d740d940095982c8f9d9e9
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
Log Message:
-----------
client/btpclient: Replace advertising defines by shared ones
The advertisement types are already defined in src/shared/ad.h
Commit: e6f7d0db186428ccb5d3734e157bc964be62a454
https://github.com/bluez/bluez/commit/e6f7d0db186428ccb5d3734e157bc964be62a454
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
M src/shared/btp.h
Log Message:
-----------
client/btpclient: Add BTP_OP_GAP_SET_EXTENDED_ADVERTISING support
This set LEAdvertisement1's SecondaryChannel property to "2M" to
force Extended advertisement type.
Compare: https://github.com/bluez/bluez/compare/0cb83cdaeb54%5E...e6f7d0db1864
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] acfd19: client/btpclient: Fix GAP unpair command
From: fdanis-oss @ 2026-05-19 11:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1097183
Home: https://github.com/bluez/bluez
Commit: acfd19a5de7a38247784c005d61c45b0f4c3c9bf
https://github.com/bluez/bluez/commit/acfd19a5de7a38247784c005d61c45b0f4c3c9bf
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
Log Message:
-----------
client/btpclient: Fix GAP unpair command
Fix unpair_reply() because the device is no more available on
RemoveDevice reply.
Commit: 05e97748b101c0c9d656c0d01f67b8877f2dab67
https://github.com/bluez/bluez/commit/05e97748b101c0c9d656c0d01f67b8877f2dab67
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M client/btpclient/gap.c
Log Message:
-----------
client/btpclient: Don't remove all devices on GAP Reset command
Currently running auto-pts remove all paired devices, instead of just
removing the PTS devices.
This removes this behavior, expecting auto-pts to explicitly remove the
PTS devices using Unpair command.
Compare: https://github.com/bluez/bluez/compare/acfd19a5de7a%5E...05e97748b101
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH v3] Bluetooth: bnep: reject short frames before parsing
From: Zhang Cen @ 2026-05-19 11:39 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.
KASAN report as below:
BUG: KASAN: slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790
Read of size 1 at addr ffff88800c0f7909
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)
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>
---
v3:
Use skb_pull_data() with NULL checks in bnep_rx_frame() instead of direct skb->len guards before fixed header dereferences.
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 853c8d7644b55..de9c872e2c9cb 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
* [bluetooth-next:master] BUILD SUCCESS 8f5b6b4b198ed661ae851daaf9cb94fe285b2648
From: kernel test robot @ 2026-05-19 11:00 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: 8f5b6b4b198ed661ae851daaf9cb94fe285b2648 Bluetooth: MGMT: validate Add Extended Advertising Data length
elapsed time: 788m
configs tested: 213
configs skipped: 17
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260519 clang-23
arc randconfig-001-20260519 gcc-9.5.0
arc randconfig-002-20260519 clang-23
arc randconfig-002-20260519 gcc-10.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm randconfig-001-20260519 clang-23
arm randconfig-002-20260519 clang-23
arm randconfig-003-20260519 clang-23
arm randconfig-004-20260519 clang-23
arm randconfig-004-20260519 gcc-8.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260519 clang-18
arm64 randconfig-001-20260519 gcc-8.5.0
arm64 randconfig-002-20260519 gcc-11.5.0
arm64 randconfig-002-20260519 gcc-8.5.0
arm64 randconfig-003-20260519 gcc-8.5.0
arm64 randconfig-004-20260519 gcc-8.5.0
arm64 randconfig-004-20260519 gcc-9.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260519 gcc-12.5.0
csky randconfig-001-20260519 gcc-8.5.0
csky randconfig-002-20260519 gcc-11.5.0
csky randconfig-002-20260519 gcc-8.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260519 clang-23
hexagon randconfig-001-20260519 gcc-10.5.0
hexagon randconfig-002-20260519 clang-23
hexagon randconfig-002-20260519 gcc-10.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260519 gcc-14
i386 randconfig-002-20260519 gcc-14
i386 randconfig-003-20260519 gcc-14
i386 randconfig-004-20260519 gcc-14
i386 randconfig-005-20260519 gcc-14
i386 randconfig-006-20260519 gcc-14
i386 randconfig-007-20260519 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260519 clang-18
loongarch randconfig-001-20260519 gcc-10.5.0
loongarch randconfig-002-20260519 gcc-10.5.0
loongarch randconfig-002-20260519 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260519 gcc-10.5.0
nios2 randconfig-001-20260519 gcc-11.5.0
nios2 randconfig-002-20260519 gcc-10.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc de0_nano_multicore_defconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260519 gcc-12.5.0
parisc randconfig-001-20260519 gcc-8.5.0
parisc randconfig-002-20260519 gcc-8.5.0
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260519 clang-23
powerpc randconfig-001-20260519 gcc-8.5.0
powerpc randconfig-002-20260519 gcc-8.5.0
powerpc64 randconfig-001-20260519 clang-23
powerpc64 randconfig-001-20260519 gcc-8.5.0
powerpc64 randconfig-002-20260519 gcc-14.3.0
powerpc64 randconfig-002-20260519 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260519 gcc-13.4.0
riscv randconfig-001-20260519 gcc-8.5.0
riscv randconfig-002-20260519 clang-17
riscv randconfig-002-20260519 gcc-13.4.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260519 clang-23
s390 randconfig-001-20260519 gcc-13.4.0
s390 randconfig-002-20260519 clang-18
s390 randconfig-002-20260519 gcc-13.4.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh defconfig gcc-15.2.0
sh randconfig-001-20260519 gcc-13.4.0
sh randconfig-001-20260519 gcc-15.2.0
sh randconfig-002-20260519 gcc-13.4.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260519 gcc-14.3.0
sparc randconfig-002-20260519 gcc-11.5.0
sparc randconfig-002-20260519 gcc-14.3.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260519 gcc-14.3.0
sparc64 randconfig-001-20260519 gcc-8.5.0
sparc64 randconfig-002-20260519 gcc-14.3.0
sparc64 randconfig-002-20260519 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260519 clang-23
um randconfig-001-20260519 gcc-14.3.0
um randconfig-002-20260519 clang-23
um randconfig-002-20260519 gcc-14.3.0
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260519 gcc-14
x86_64 buildonly-randconfig-002-20260519 gcc-14
x86_64 buildonly-randconfig-003-20260519 clang-20
x86_64 buildonly-randconfig-004-20260519 clang-20
x86_64 buildonly-randconfig-005-20260519 gcc-14
x86_64 buildonly-randconfig-006-20260519 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-011 clang-20
x86_64 randconfig-011-20260519 clang-20
x86_64 randconfig-012 clang-20
x86_64 randconfig-012-20260519 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260519 clang-20
x86_64 randconfig-014 clang-20
x86_64 randconfig-014-20260519 clang-20
x86_64 randconfig-015 clang-20
x86_64 randconfig-015-20260519 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260519 clang-20
x86_64 randconfig-071-20260519 gcc-14
x86_64 randconfig-072-20260519 gcc-14
x86_64 randconfig-073-20260519 gcc-14
x86_64 randconfig-074-20260519 gcc-14
x86_64 randconfig-075-20260519 gcc-14
x86_64 randconfig-076-20260519 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260519 gcc-10.5.0
xtensa randconfig-001-20260519 gcc-14.3.0
xtensa randconfig-002-20260519 gcc-10.5.0
xtensa randconfig-002-20260519 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: Thorsten Leemhuis @ 2026-05-19 10:53 UTC (permalink / raw)
To: Greg KH
Cc: stable@vger.kernel.org, Sasha Levin, linux-bluetooth, netdev,
Luiz Augusto von Dentz, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <2026051954-revision-sierra-6bb4@gregkh>
On 5/19/26 12:30, Greg KH wrote:
> On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
>> On 5/15/26 17:10, Thorsten Leemhuis wrote:
>>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>>>
>>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>>>
>>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>>>
>>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>>>
>>> It seems this PR sadly came too late for this week's net PR to mainline
>>> that was merged yesterday.
>>>
>>> TWIMC, from my point of view, it would be great if we somehow could
>>> still get the changes from this PR or at least the btmtk fix it
>>> contains[1] to mainline this week before -rc4, as it is fixing a
>>> regression known since 2026-04-24 that at least five people encountered
>>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
>>> validate WMT event SKB length before struct access") [006b9943b982 in
>>> -next].
>>
>> Greg, Sasha, that [1] fix I was talking about now reached -next as
>> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
>> events") and will likely hit mainline on Thursday or so with the weekly
>> -net PR to -mainline. If that's good enough for you, I'd say it would be
>> good to pick this up for the next round of stable kernels.
>
> That "Fixes:" tag is referring to something that is also not in any
> tree, but that commit does have a cc: stable in it. So do we need both
> of these:
Valid question, as yes, there is a slight mixup here:
> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
-next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
btmtk: validate WMT event SKB length before struct access") -- the one
that is causing the regression that I want to get fixed. So we now only
need:
> 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
thx!
Ciao, Thorsten
^ permalink raw reply
* [PATCH BlueZ 2/3] client/btpclient: Replace advertising defines by shared ones
From: Frédéric Danis @ 2026-05-19 10:55 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260519105519.226648-1-frederic.danis@collabora.com>
The advertisement types are already defined in src/shared/ad.h
---
client/btpclient/gap.c | 44 ++++++++++++++++--------------------------
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/client/btpclient/gap.c b/client/btpclient/gap.c
index 916626f1d..2d393dd4d 100644
--- a/client/btpclient/gap.c
+++ b/client/btpclient/gap.c
@@ -17,6 +17,7 @@
#include "bluetooth/bluetooth.h"
#include "bluetooth/uuid.h"
+#include "src/shared/ad.h"
#include "src/shared/btp.h"
#include "btpclient.h"
#include "core.h"
@@ -27,17 +28,6 @@
#define AD_IFACE "org.bluez.LEAdvertisement1"
#define AG_IFACE "org.bluez.Agent1"
-/* List of assigned numbers for advertising data and scan response */
-#define AD_TYPE_FLAGS 0x01
-#define AD_TYPE_INCOMPLETE_UUID16_SERVICE_LIST 0x02
-#define AD_TYPE_SHORT_NAME 0x08
-#define AD_TYPE_COMPLETE_NAME 0x09
-#define AD_TYPE_TX_POWER 0x0a
-#define AD_TYPE_SOLICIT_UUID16_SERVICE_LIST 0x14
-#define AD_TYPE_SERVICE_DATA_UUID16 0x16
-#define AD_TYPE_APPEARANCE 0x19
-#define AD_TYPE_MANUFACTURER_DATA 0xff
-
static void register_gap_service(void);
static struct l_dbus *dbus;
@@ -899,7 +889,7 @@ static void create_advertising_data(uint8_t adv_data_len, const uint8_t *data)
ad_data = &data[adv_data_len - remaining_data_len + 2];
switch (ad_type) {
- case AD_TYPE_INCOMPLETE_UUID16_SERVICE_LIST:
+ case BT_AD_UUID16_SOME:
{
char *uuid = dupuuid2str(ad_data, 16);
@@ -907,20 +897,28 @@ static void create_advertising_data(uint8_t adv_data_len, const uint8_t *data)
break;
}
- case AD_TYPE_SHORT_NAME:
- case AD_TYPE_COMPLETE_NAME:
+ case BT_AD_NAME_SHORT:
+ case BT_AD_NAME_COMPLETE:
ad.local_name = malloc(ad_len + 1);
memcpy(ad.local_name, ad_data, ad_len);
ad.local_name[ad_len] = '\0';
break;
- case AD_TYPE_TX_POWER:
+ case BT_AD_TX_POWER:
ad.tx_power = true;
/* XXX Value is omitted cause, stack fills it */
break;
- case AD_TYPE_SERVICE_DATA_UUID16:
+ case BT_AD_SOLICIT16:
+ {
+ char *uuid = dupuuid2str(ad_data, 16);
+
+ l_queue_push_tail(ad.solicits, uuid);
+
+ break;
+ }
+ case BT_AD_SERVICE_DATA16:
{
struct service_data *sd;
@@ -933,11 +931,11 @@ static void create_advertising_data(uint8_t adv_data_len, const uint8_t *data)
break;
}
- case AD_TYPE_APPEARANCE:
+ case BT_AD_GAP_APPEARANCE:
memcpy(&ad.local_appearance, ad_data, ad_len);
break;
- case AD_TYPE_MANUFACTURER_DATA:
+ case BT_AD_MANUFACTURER_DATA:
{
struct manufacturer_data *md;
@@ -954,14 +952,6 @@ static void create_advertising_data(uint8_t adv_data_len, const uint8_t *data)
break;
}
- case AD_TYPE_SOLICIT_UUID16_SERVICE_LIST:
- {
- char *uuid = dupuuid2str(ad_data, 16);
-
- l_queue_push_tail(ad.solicits, uuid);
-
- break;
- }
default:
l_info("Unsupported advertising data type");
@@ -2455,7 +2445,7 @@ static void btp_gap_device_found_ev(struct l_dbus_proxy *proxy)
ev->eir_len);
eir = &ev->eir[ev->eir_len - n - 4];
eir[0] = n + 3;
- eir[1] = AD_TYPE_MANUFACTURER_DATA;
+ eir[1] = BT_AD_MANUFACTURER_DATA;
eir[2] = key >> 8;
eir[3] = key & 0xFF;
memcpy(&eir[4], data, n);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox