From nobody Sat Jun 13 07:50:31 2026 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EED85410D34 for ; Fri, 8 May 2026 17:32:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778261565; cv=none; b=k1AGiTOvwut3jpGZznqZ/Z/ggQ1eXhDhhv3oQQwb2/5Mih8roXyBWo0FV8V7ZoXy+kBuIsR/eN6ECJBR3Dn2aBrVpLVQsCAw/mWWnPgNkK+lrv2Ng7Y5zYwAN127Keoi2+sW0owJedkBV7dAZ6fNSnLw5oc01+uuT5Uv2Rm41gM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778261565; c=relaxed/simple; bh=LplV3crLjJFyz1CKIX58/3G5oyVUNzkN7/tKutv6ISY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=d+MiApHmr3hv+w/FfQ7m8FX+UcxYflgWH18IrD1X6ExcyDKZH4A9Xs+RxZp53CE8Oc5rlSvbSmzCq5cs4pWpIVCqiQfhpgGBLXHTkg7yGRkTg138E8ob1+6hjbm6X2AjvcSXQ5xqlz3pGmzTD8STpmMvuLHZnSyYt36dWmBEkew= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SagMxUA7; arc=none smtp.client-ip=209.85.208.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SagMxUA7" Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-39396f873adso25974381fa.3 for ; Fri, 08 May 2026 10:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778261561; x=1778866361; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=JKiWj7c3WOUi3B7MNwmGjdVqB1Ve1n7R+SIRjPXohtk=; b=SagMxUA7DK+tK3LCVK2O37xqlwyhcfZciQbXK6LT/efDfzuVN92NUthqKYR51g5am/ k6npWXBITfrRzZTwnqCwnIV8niBV5lO7SYXXD2Gw9PeWWrmpYtzy7ZCajReHLIhzyA5K Fa6nQEnkUCXjpE5zf4sXHhBHGCgiROsnL2QKqESIHpTEDsOixoRlH62lhF4wcDXvK1kO lmsyr+tMUTwQOp3FryKYClaLMMfQyDCQIeZuUcfdblYhqUJnIXq1XFdgIrpXmWmdLiwt hESFk2okLYHoNJt90JfZKNoy/c4UQuP9C8OEmeMPCRiuKwT9EzIvLRmIP6CuMdtSqM5Q j0tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778261561; x=1778866361; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JKiWj7c3WOUi3B7MNwmGjdVqB1Ve1n7R+SIRjPXohtk=; b=TEoZHjct6wHNbWXbATwoEhuCFbhll/Bgpdvpj+2+y1IbtKaheFABUMw/Z6mUMNi0Ie zSSCfgWU2fPkOJueFMYWMNbnfyBLcGJz86xjVxgd/j5uXFn7C4ZSDM1tJ5nRxXt6tS3V Bgb+O9rMxRx5UT6exGBkx+G+6GZTzY5EcH1GW9XivQnjREo+vokLKe1kwlbJLelwVd5E BGOlNeqL5OkFDUe94lsWK3JcSoRKFrn8JSx5LfcjPLBdJP0ml57vvfXeSfsn+Umh+Bwf kXws4HQn3vJmgmMK5IvzjEUszkPsXwvPuvwgXdoAyXXOe4UK2oUn9sYGgPsKG31Ewa9w Oa1w== X-Forwarded-Encrypted: i=1; AFNElJ+DM6teSfdYLU/oCDUs2oiTV4bbHIjNShbkA6c/YXWi48qfX+dL3VQiTp/9OyHl0zwpYvJ9tmEyk3WCrO8=@vger.kernel.org X-Gm-Message-State: AOJu0YzMLp1g+V2YQHYN14ShN65NS9ntGruqHQmkP5XRjr+MaNuRdRc+ dxRZuPOfqWhzBe2uthkKHRvTswwh4sqUgwDkNZqwEVYU7nrFns523GHP X-Gm-Gg: Acq92OETO2wDyHxVeCl0OWcKrnDSmmDTO3zDYtNGEUnlfLeKNL0pzFlx5NG67qqDm8d SLTqW6MZ6XTZFMD6ZhR3ejoaIjo/0vSjXlh4cLT4nP8sRVa36Rp/lbS6rfJf2sFySxWbmmcYt8h XhIRtSf85zOLyLbBnQOqAhOJwzt51f9eKVbiBIuKOHK7/U2dsd2ypAXsbaNSjtHzvzFgiye+ZNX 8IvxjKzs8czYj7FRFTP11LJS8eZL/RRDT84ZmDvxICF9DQ4tveFNsVtFe7o6JSZr0WmccjSaZyU XRYtT2mjQ9il7UQUH7tSQNKnRuj1LXYs0mDpz7+eotYvD1YH1H07ysuhwj+Qe9wW1yTwIMWxHoe Oo7YoO1RKknuWSKg3sfCDQrAEogfTEnQTeV6GjnufiKY6xEjBF4T0qUnKe+o9NhUA9eA0LE92Ii eUyYlo8xkhHIAwUVebxGM2YP0f1/yRcUpC3oouzT/frYFw X-Received: by 2002:a2e:98d0:0:b0:38e:90b9:ce98 with SMTP id 38308e7fff4ca-393c40cbb63mr38714761fa.6.1778261560643; Fri, 08 May 2026 10:32:40 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-393f6144071sm6162291fa.32.2026.05.08.10.32.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 10:32:39 -0700 (PDT) From: Mikhail Gavrilov To: Marcel Holtmann , Luiz Augusto von Dentz Cc: Johan Hedberg , Tristan Madani , linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Mikhail Gavrilov Subject: [PATCH] Bluetooth: btmtk: handle FUNC_CTRL events without status field Date: Fri, 8 May 2026 22:31:21 +0500 Message-ID: <20260508173121.27526-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 befor= e struct access") Cc: stable@vger.kernel.org Cc: Tristan Madani Tested-by: Mikhail Gavrilov # MT7922 (0489:e= 0e2) Signed-off-by: Mikhail Gavrilov Reviewed-by: Tristan Madani --- 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 =3D -EINVAL; - goto err_free_skb; + bt_dev_dbg(hdev, + "FUNC_CTRL event without status, assuming UNDONE"); + status =3D BTMTK_WMT_ON_UNDONE; + break; } =20 wmt_evt_funcc =3D (struct btmtk_hci_wmt_evt_funcc *)wmt_evt; --=20 2.54.0