From nobody Fri Sep 25 10:37:07 2026 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F324538D40B; Mon, 14 Sep 2026 06:57:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.61.82.184 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369027; cv=none; b=T7xz7MMTgMOYYMRPR+64+ZD4g3cJ+EEZWJSCs+JwAZe9kuQjsAygpANbp2xIGUCVccp9F48X/VGim6t97idgn842IF4RleMCpFQV55hBGGmD0DPN9leR15nFI+Re+bcuxwE36qGbate2XBbOaNeTBnlm6/pi161LMNHin4Ad6uw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369027; c=relaxed/simple; bh=InWnSchOFmtnDRRPOkDjuk0ggAfdGCXzi6qozZkDWfA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jHyTZx6SXdH1hEI3L2OXWffov8P9vTAc/2QevJyN1+IfGsKq50dCNPwJN8yNNl6tb1LeVUxkAb9eghfPTsJPGktW0tlAgVLXPZtvY5DCJA6MnFHlvO9yOK48PzUVxgEmt3Pn09uLnnWLwAwZSiOt7LE0mpJPDVQx3mw7lAPjdW0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b=QjsUH/4Q; arc=none smtp.client-ip=210.61.82.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mediatek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="QjsUH/4Q" X-UUID: 79f0179ab00911f18dc8c9802ae25ab1-20260914 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=NGfrSwb7kUfROhwGV7OHlue/a5Pn2gN3pKAVCv80KqY=; b=QjsUH/4QvL1OsWH7h7+UFLpST3Bb/4s2CoFtym961Zb8r0OPCgfarsLxRyT1Az/P/w8NL6+8x2sGqq1uj0Llg5+6iWLidTZraDVAhGBAd11jByJ9lCBBT7y6xHxzaaOR7uBYBhCOYWfKA4xsm8gpoF8R3oAGC0huB178DF4kwQ0=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.19,REQID:f1bda98c-6277-4dbe-9874-ca6202d83bfb,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:7db8b62,CLOUDID:1b153fd1-f9b0-4ba3-931f-dd1de252a72d,B ulkID:nil,BulkQuantity:0,SF:81|82|102|836|865|888|898,TC:-5,Content:0|15|5 0|99,EDM:-3,IP:nil,URL:0,File:130,RT:0,Bulk:nil,QS:nil,BEC:-1,COL:0,OSI:0, OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: 79f0179ab00911f18dc8c9802ae25ab1-20260914 Received: from mtkmbs14n2.mediatek.inc [(172.21.101.76)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1958883300; Mon, 14 Sep 2026 14:56:57 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by mtkmbs11n1.mediatek.inc (172.21.101.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Mon, 14 Sep 2026 14:56:55 +0800 Received: from mtksitap99.mediatek.inc (10.233.130.16) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Mon, 14 Sep 2026 14:56:55 +0800 From: Chris Lu To: Marcel Holtmann , Johan Hedberg , Luiz Von Dentz CC: Sean Wang , Will Lee , SS Wu , linux-bluetooth , linux-kernel , linux-mediatek , Chris Lu Subject: [PATCH v2 1/3] Bluetooth: btmtk: Route firmware debug event to the diag channel Date: Mon, 14 Sep 2026 14:56:52 +0800 Message-ID: <20260914065654.102916-2-chris.lu@mediatek.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20260914065654.102916-1-chris.lu@mediatek.com> References: <20260914065654.102916-1-chris.lu@mediatek.com> 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" MediaTek controllers may emit a firmware debug event on the ACL channel using the reserved handle 0x0efd, which shows up in the ACL header as 0x2efd once the start fragment flag is included. Neither btmtk_usb_recv_acl() nor btmtksdio_recv_acl() recognizes it, so the packet is passed to the HCI core, which has no connection with that handle and complains: Bluetooth: hci0: ACL packet for unknown connection handle 3837 Handle it the same way as the existing firmware debug logging packets and forward it to the diagnostic channel instead. Confirmed with MTK internally that this event's wire format is fixed: firmware always sends it as a single ACL_START packet and never splits it into a continuation (ACL_CONT, which would show up as 0x1efd). Add a comment above the switch spelling that out for this and the other vendor-reserved handles already handled here (0xfc6f, 0x05ff, 0x05fe), so review tooling doesn't keep flagging the apparent lack of a matching continuation case. Verified on MT7922: under the condition that triggers this firmware debug event, it is now routed to the diag channel instead of reaching the host as an unknown ACL packet. Signed-off-by: Chris Lu --- v2: Confirmed with MTK that this event's wire format is fixed at a single ACL_START packet; added a comment above the switch in btmtk.c and btmtksdio.c explaining that HCI fragmentation does not apply here, addressing review feedback on v1. drivers/bluetooth/btmtk.c | 8 ++++++++ drivers/bluetooth/btmtksdio.c | 8 ++++++++ 2 files changed, 16 insertions(+) diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c index 660ed5b02841..ddf50ab9533e 100644 --- a/drivers/bluetooth/btmtk.c +++ b/drivers/bluetooth/btmtk.c @@ -1055,6 +1055,13 @@ int btmtk_usb_recv_acl(struct hci_dev *hdev, struct = sk_buff *skb) struct btmtk_data *data =3D hci_get_priv(hdev); u16 handle =3D le16_to_cpu(hci_acl_hdr(skb)->handle); + /* The handles below are vendor-reserved values MTK firmware uses to + * tag out-of-band debug/dump data on the ACL channel rather than a + * real connection. Each is always sent as a single, complete + * ACL_START packet, so unlike genuine connection data they never + * arrive fragmented (e.g. 0x2efd is never followed by an ACL_CONT + * continuation, 0x1efd). + */ switch (handle) { case 0xfc6f: /* Firmware dump from device */ /* When the firmware hangs, the device can no longer @@ -1076,6 +1083,7 @@ int btmtk_usb_recv_acl(struct hci_dev *hdev, struct s= k_buff *skb) fallthrough; case 0x05ff: /* Firmware debug logging 1 */ case 0x05fe: /* Firmware debug logging 2 */ + case 0x2efd: /* Firmware debug event */ return hci_recv_diag(hdev, skb); } diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c index fe4ca9395aa3..46cb143a99c6 100644 --- a/drivers/bluetooth/btmtksdio.c +++ b/drivers/bluetooth/btmtksdio.c @@ -451,6 +451,13 @@ static int btmtksdio_recv_acl(struct hci_dev *hdev, st= ruct sk_buff *skb) struct btmtksdio_dev *bdev =3D hci_get_drvdata(hdev); u16 handle =3D le16_to_cpu(hci_acl_hdr(skb)->handle); + /* The handles below are vendor-reserved values MTK firmware uses to + * tag out-of-band debug/dump data on the ACL channel rather than a + * real connection. Each is always sent as a single, complete + * ACL_START packet, so unlike genuine connection data they never + * arrive fragmented (e.g. 0x2efd is never followed by an ACL_CONT + * continuation, 0x1efd). + */ switch (handle) { case 0xfc6f: /* Firmware dump from device: when the firmware hangs, the @@ -460,6 +467,7 @@ static int btmtksdio_recv_acl(struct hci_dev *hdev, str= uct sk_buff *skb) fallthrough; case 0x05ff: case 0x05fe: + case 0x2efd: /* Firmware debug event */ /* Firmware debug logging */ return hci_recv_diag(hdev, skb); } -- 2.45.2 From nobody Fri Sep 25 10:37:07 2026 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B182D30596F; Mon, 14 Sep 2026 06:57:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.244.123.138 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369026; cv=none; b=XeaFS8+zAXSnosq0zlWfgbuSTFNnvrZRuGty9RnsNHVfmJIa7lab6V6WobzShShKDc+fX+MX9ooOAu4rqWFFct/BS2LSR1ZFFNyqgPq9Zj6qKfxLFlNZlair9CCWV8DiWTaCW9f+Rqjang0ayw3l349qk3ooOmyikCatC1ZexUY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369026; c=relaxed/simple; bh=IiAcSEjEkweZsqW5rZZe70kiLnEjvojllzLM8y47S0g=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lJvA3LWAWBPYMvYt+EPYhUCsaPbh4W8ZUzoAtiKpDztoF7KEeI3v5AnVmSyzSbfRecwtVperqolZ1rQPIe0hxTCq5/m2fZ8V3g0+4q5xUBWobpUDvx9XxFTbVj734Mvl6ULtCb9TK/p6wc2cvG3zSvaC6I7zb9j72nm736La5xE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b=OtmI+C9M; arc=none smtp.client-ip=60.244.123.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mediatek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="OtmI+C9M" X-UUID: 79fa9a4eb00911f1b1788b6acf885367-20260914 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=M+wbLc+QMBDELQI8j8VkH4b0X7LtW4k6/J0pAV5Iqbs=; b=OtmI+C9MKMDFcnCjc30dum+qfyP47pftd2WfmvaAOoxRYUT9dirCZc20Qbf0LKYcIW9peIeYfcPMdXaDcDxvLNMv3hIQgLKy054w2hKNG6RNk5Se7Gk5RXEUqDXyR2MhPkDyJGmTiK4Y9yFOHWvFmpdsp8IwYAPYue+5d/nZHJI=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.19,REQID:9351ce3e-d6aa-47b6-afc8-c5d9dedfad89,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:7db8b62,CLOUDID:a5593c0c-027a-4b0a-91ab-050fa8cdb9b0,B ulkID:nil,BulkQuantity:0,SF:81|82|102|136|836|865|888|898,TC:-5,Content:0| 15|50|99,EDM:-3|-100,IP:nil,URL:0,File:130,RT:0,Bulk:nil,QS:nil,BEC:-1,COL :0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: 79fa9a4eb00911f1b1788b6acf885367-20260914 Received: from mtkmbs13n2.mediatek.inc [(172.21.101.108)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1534605908; Mon, 14 Sep 2026 14:56:57 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by mtkmbs11n2.mediatek.inc (172.21.101.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Mon, 14 Sep 2026 14:56:55 +0800 Received: from mtksitap99.mediatek.inc (10.233.130.16) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Mon, 14 Sep 2026 14:56:56 +0800 From: Chris Lu To: Marcel Holtmann , Johan Hedberg , Luiz Von Dentz CC: Sean Wang , Will Lee , SS Wu , linux-bluetooth , linux-kernel , linux-mediatek , Chris Lu Subject: [PATCH v2 2/3] Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events Date: Mon, 14 Sep 2026 14:56:53 +0800 Message-ID: <20260914065654.102916-3-chris.lu@mediatek.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20260914065654.102916-1-chris.lu@mediatek.com> References: <20260914065654.102916-1-chris.lu@mediatek.com> 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 too-short BTMTK_WMT_FUNC_CTRL event (WMT header only, no trailing 2-byte status word) is always treated as BTMTK_WMT_ON_UNDONE. This short form is how firmware acks a plain enable/disable request, and the actual result is carried in the header's own flag byte (0 =3D success), not a separate status word. Decode it from there instead of assuming failure. Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: e3ac0d9f1a20 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL even= ts") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu --- v2: No changes. drivers/bluetooth/btmtk.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c index 660ed5b02841..03b99826b52c 100644 --- a/drivers/bluetooth/btmtk.c +++ b/drivers/bluetooth/btmtk.c @@ -791,7 +791,12 @@ 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))) { - status =3D BTMTK_WMT_ON_UNDONE; + /* A plain enable/disable request is acked with just + * the WMT header and no trailing status word; the + * result is carried in the header's own flag byte. + */ + status =3D wmt_evt->whdr.flag ? BTMTK_WMT_ON_UNDONE : + BTMTK_WMT_ON_DONE; break; } -- 2.45.2 From nobody Fri Sep 25 10:37:07 2026 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2124386C1E; Mon, 14 Sep 2026 06:57:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.61.82.184 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369025; cv=none; b=r0LEFguThQCVMQsvaj35xLYs+1wYs9/qZ8pvLMeQ3cr1CgaAFLveJbrKaRnRjD8vBrqCQ+cw/UYko+nthU5oh6qRMwebpfOEzaj0DcI5B749r1PfjGmYYacZMOGvGI1nOywNp9IqJV8QuWLrA8A1lrtIR+zMkkNk7bWNTBLNoZ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789369025; c=relaxed/simple; bh=MDxM7dSpfQOUDIcSrQpWJsOAnAgKZhcVdCo2YnM8+eU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=C+s8KwZdCgxa5v0k+GaencOIz1Inbvnbsy8AP2frRBNym6TOcNN5gQXb7UmqUbrts2Ngmsnibe+bNWI3epPrSSWK22NndzbokPvtC5zYAXeQ0m3fXjb7GzeVU/Qum9BKFlc6VvB8kI/IpOqm3w6dCm+IB7u0t+43hvfrouJYXDs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b=EbPHmEKK; arc=none smtp.client-ip=210.61.82.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mediatek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="EbPHmEKK" X-UUID: 7a21b6e2b00911f18dc8c9802ae25ab1-20260914 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=rZRoEPHXjuV79l1ybcBgULgJeqaTK4JuMEG1rlo45wc=; b=EbPHmEKKJnMrqzR0ObYz0WujWkQCbEoeWdB6WX9xak3Zd/vB6VKjo60MPIi4fhXvuMmtfc1Ych85xIoMOK4ZL5jIFUxkmaL0cPSZDE5VDc2aRsOkMI9Z0hLeCrSCMABUaOJdT+hcZHWHsc0VzaxJt3PAKYGIsddOzpL3y2WnL5c=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.19,REQID:273f5640-b8e3-425b-a9a7-fb7be9854bd5,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:7db8b62,CLOUDID:1c153fd1-f9b0-4ba3-931f-dd1de252a72d,B ulkID:nil,BulkQuantity:0,SF:81|82|102|836|865|888|898,TC:-5,Content:0|15|5 0|99,EDM:-3,IP:nil,URL:0,File:130,RT:0,Bulk:nil,QS:nil,BEC:-1,COL:0,OSI:0, OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: 7a21b6e2b00911f18dc8c9802ae25ab1-20260914 Received: from mtkmbs11n2.mediatek.inc [(172.21.101.187)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 836476836; Mon, 14 Sep 2026 14:56:57 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by MTKMBS14N1.mediatek.inc (172.21.101.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Mon, 14 Sep 2026 14:56:56 +0800 Received: from mtksitap99.mediatek.inc (10.233.130.16) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Mon, 14 Sep 2026 14:56:56 +0800 From: Chris Lu To: Marcel Holtmann , Johan Hedberg , Luiz Von Dentz CC: Sean Wang , Will Lee , SS Wu , linux-bluetooth , linux-kernel , linux-mediatek , Chris Lu Subject: [PATCH v2 3/3] Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access Date: Mon, 14 Sep 2026 14:56:54 +0800 Message-ID: <20260914065654.102916-4-chris.lu@mediatek.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20260914065654.102916-1-chris.lu@mediatek.com> References: <20260914065654.102916-1-chris.lu@mediatek.com> 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" btmtksdio.c and btmtkuart.c cast a received WMT event straight to struct btmtk_hci_wmt_evt and read its op/flag fields without checking the event is long enough to contain them, unlike btmtk.c. The FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc and reads its 2-byte status field, again without a length check. Firmware that sends a short or malformed WMT event makes both drivers read past the end of the received SKB. Mirror btmtk.c: validate the base WMT header with skb_pull_data() before touching any of its fields, and when a FUNC_CTRL event turns out to be the short, header-only form (a plain enable/disable ack with no status word), decode the result from the header's own flag byte instead (0 =3D success, otherwise failure). Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S= and MT7668S SDIO devices") Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between = MT7622 and other devices") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu --- v2: No changes. drivers/bluetooth/btmtksdio.c | 20 +++++++++++++++++++- drivers/bluetooth/btmtkuart.c | 20 +++++++++++++++++++- 2 files changed, 38 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c index fe4ca9395aa3..a8ebcd0c005c 100644 --- a/drivers/bluetooth/btmtksdio.c +++ b/drivers/bluetooth/btmtksdio.c @@ -217,7 +217,14 @@ static int mtk_hci_wmt_sync(struct hci_dev *hdev, } /* Parse and handle the return WMT event */ - wmt_evt =3D (struct btmtk_hci_wmt_evt *)bdev->evt_skb->data; + wmt_evt =3D skb_pull_data(bdev->evt_skb, sizeof(*wmt_evt)); + if (!wmt_evt) { + bt_dev_err(hdev, "WMT event too short (%u bytes)", + bdev->evt_skb->len); + err =3D -EINVAL; + goto err_free_skb; + } + if (wmt_evt->whdr.op !=3D hdr->op) { bt_dev_err(hdev, "Wrong op received %d expected %d", wmt_evt->whdr.op, hdr->op); @@ -233,6 +240,17 @@ static int mtk_hci_wmt_sync(struct hci_dev *hdev, status =3D BTMTK_WMT_PATCH_DONE; break; case BTMTK_WMT_FUNC_CTRL: + if (!skb_pull_data(bdev->evt_skb, + sizeof(wmt_evt_funcc->status))) { + /* A plain enable/disable request is acked with just + * the WMT header and no trailing status word; the + * result is carried in the header's own flag byte. + */ + status =3D wmt_evt->whdr.flag ? BTMTK_WMT_ON_UNDONE : + BTMTK_WMT_ON_DONE; + break; + } + wmt_evt_funcc =3D (struct btmtk_hci_wmt_evt_funcc *)wmt_evt; if (be16_to_cpu(wmt_evt_funcc->status) =3D=3D 0x404) status =3D BTMTK_WMT_ON_DONE; diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c index 27aa48ff3ac2..4af6fbbbd302 100644 --- a/drivers/bluetooth/btmtkuart.c +++ b/drivers/bluetooth/btmtkuart.c @@ -151,7 +151,14 @@ static int mtk_hci_wmt_sync(struct hci_dev *hdev, } /* Parse and handle the return WMT event */ - wmt_evt =3D (struct btmtk_hci_wmt_evt *)bdev->evt_skb->data; + wmt_evt =3D skb_pull_data(bdev->evt_skb, sizeof(*wmt_evt)); + if (!wmt_evt) { + bt_dev_err(hdev, "WMT event too short (%u bytes)", + bdev->evt_skb->len); + err =3D -EINVAL; + goto err_free_wc; + } + if (wmt_evt->whdr.op !=3D hdr->op) { bt_dev_err(hdev, "Wrong op received %d expected %d", wmt_evt->whdr.op, hdr->op); @@ -167,6 +174,17 @@ static int mtk_hci_wmt_sync(struct hci_dev *hdev, status =3D BTMTK_WMT_PATCH_DONE; break; case BTMTK_WMT_FUNC_CTRL: + if (!skb_pull_data(bdev->evt_skb, + sizeof(wmt_evt_funcc->status))) { + /* A plain enable/disable request is acked with just + * the WMT header and no trailing status word; the + * result is carried in the header's own flag byte. + */ + status =3D wmt_evt->whdr.flag ? BTMTK_WMT_ON_UNDONE : + BTMTK_WMT_ON_DONE; + break; + } + wmt_evt_funcc =3D (struct btmtk_hci_wmt_evt_funcc *)wmt_evt; if (be16_to_cpu(wmt_evt_funcc->status) =3D=3D 0x404) status =3D BTMTK_WMT_ON_DONE; -- 2.45.2