Re: [PATCH 0/3] Bluetooth: btmtk: firmware debug event routing and WMT FUNC_CTRL status fixes

From: Luiz Augusto von Dentz

Date: Fri Sep 11 2026 - 10:50:39 EST


Hi Chris,

On Fri, Sep 11, 2026 at 6:42 AM Chris Lu <chris.lu@xxxxxxxxxxxx> wrote:
>
> This series bundles three independent MediaTek Bluetooth driver fixes:
>
> Patch 1 is a resend of a fix submitted on 25 Aug 2026
> ("Bluetooth: btmtk: Route firmware debug event to the diag channel")
> that received no review feedback. There are no code changes since
> that submission; resending it alongside the two related fixes below.
>
> Patches 2-3 fix how btmtk_usb_hci_wmt_sync() (and its btmtksdio.c /
> btmtkuart.c counterparts) interpret a WMT FUNC_CTRL event that carries
> only the WMT header and no trailing 2-byte status word. Such an event
> is a normal firmware ack for a plain enable/disable request, with the
> result carried in the header's own flag byte, not a failure as the
> current code assumes:
>
> - Patch 2 fixes this for btmtk.c, where a bounds check already
> existed (added by e3ac0d9f1a20) but defaulted to the wrong
> result.
> - Patch 3 applies the same fix to btmtksdio.c and btmtkuart.c, which
> never had a bounds check for this event at all and read 2 bytes
> past the end of the received SKB whenever firmware sent the short
> form. While there, it also adds the missing base WMT header length
> check that btmtk.c already has (skb_pull_data() before touching
> wmt_evt->whdr.op), since these two files were unconditionally
> dereferencing that field with no length validation at all.
>
> Chris Lu (3):
> Bluetooth: btmtk: Route firmware debug event to the diag channel
> Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events
> Bluetooth: btmtksdio, btmtkuart: validate WMT event length before
> struct access
>
> drivers/bluetooth/btmtk.c | 8 +++++++-
> drivers/bluetooth/btmtksdio.c | 20 +++++++++++++++++++-
> drivers/bluetooth/btmtkuart.c | 19 ++++++++++++++++++-
> 3 files changed, 44 insertions(+), 3 deletions(-)
>
> --
> 2.45.2

Sashiko flagged a problem regarding the usage of ACL connection handle
without masking the PB field:

https://sashiko.dev/#/patchset/20260911104234.2276126-1-chris.lu%40mediatek.com

If the HCI fragmentation doesn't apply to these handles, please add a
comment regarding it; otherwise, users like Sashiko will keep flagging
it going forward.


--
Luiz Augusto von Dentz