[PATCH] Bluetooth: btmtk: handle FUNC_CTRL events without status field

[PATCH] Bluetooth: btmtk: handle FUNC_CTRL events without status field

[Mikhail Gavrilov]

A WMT FUNC_CTRL response shorter than struct btmtk_hci_wmt_evt_funcc
(9 bytes; WMT header plus a 2-byte big-endian status) makes
btmtk_usb_hci_wmt_sync() fail with -EINVAL.  This regresses Bluetooth
initialization on MediaTek MT7922 (e.g. USB id 0489:e0e2; reproduced
with firmware 0x008a008a, build 20260224103448): the FUNC_CTRL response
from the controller is 7 bytes long and the second skb_pull_data() in
the FUNC_CTRL case returns NULL, aborting setup:

  Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
  Bluetooth: hci0: Failed to send wmt func ctrl (-22)

Reverting the offending commit on top of v7.1-rc2 restores Bluetooth
on the affected hardware.

The pre-existing code dereferenced wmt_evt_funcc->status out of the
SKB tailroom in this case -- the original out-of-bounds read that the
offending commit correctly closes.  The byte pair read OOB almost
never matched 0x404 (ON_DONE) or 0x420 (ON_PROGRESS), so the else
branch ran and the caller observed BTMTK_WMT_ON_UNDONE.  That value
lets btmtk_usb_setup() proceed: for func_query it means "not yet
enabled, issue enable", and for the enable command it means "treat
as not done", both of which keep setup advancing rather than aborting
it.

Preserve that effective behaviour explicitly: when the status field
is absent, set status to BTMTK_WMT_ON_UNDONE instead of failing.
The OOB read remains closed, since skb_pull_data() still validates
the length before any further access.

Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
Cc: stable@vger.kernel.org
Cc: Tristan Madani <tristan@talencesecurity.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> # MT7922 (0489:e0e2)
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
---
 drivers/bluetooth/btmtk.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index f70c1b0f8990..fb4875760164 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -719,8 +719,10 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
 	case BTMTK_WMT_FUNC_CTRL:
 		if (!skb_pull_data(data->evt_skb,
 				   sizeof(wmt_evt_funcc->status))) {
-			err = -EINVAL;
-			goto err_free_skb;
+			bt_dev_dbg(hdev,
+				   "FUNC_CTRL event without status, assuming UNDONE");
+			status = BTMTK_WMT_ON_UNDONE;
+			break;
 		}
 
 		wmt_evt_funcc = (struct btmtk_hci_wmt_evt_funcc *)wmt_evt;
-- 
2.54.0

RE: Bluetooth: btmtk: handle FUNC_CTRL events without status field

[bluez.test.bot]

[-- 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=1091757

---Test result---

Test Summary:
CheckPatch                    PASS      0.77 seconds
GitLint                       PASS      0.35 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      24.70 seconds
CheckAllWarning               PASS      27.71 seconds
CheckSparse                   PASS      26.44 seconds
BuildKernel32                 PASS      24.94 seconds
TestRunnerSetup               PASS      529.49 seconds
IncrementalBuild              PASS      26.83 seconds



https://github.com/bluez/bluetooth-next/pull/157

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: btmtk: handle FUNC_CTRL events without status field

[Tristan Madani]

On Fri, 2026-05-08 at 22:31 +0500, Mikhail Gavrilov wrote:
> Preserve that effective behaviour explicitly: when the status field
> is absent, set status to BTMTK_WMT_ON_UNDONE instead of failing.
> The OOB read remains closed, since skb_pull_data() still validates
> the length before any further access.

Makes sense. The hard -EINVAL was too strict for controllers that
legitimately omit the status field -- falling back to UNDONE preserves
the pre-fix behavior without reopening the OOB read.

Reviewed-by: Tristan Madani <tristan@talencesecurity.com>