From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=210.61.82.184 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792639323; b=0vyImfYzwGCnuCeUsZcqPykgkeYAva76M/gVw0PgKT6a5XcgurXkat/rP1EBAd3R0wwh 9e4QC4l76npHVWNVoP2uw2ZKbGcCc0YAoCXZZYlNdlDveuOuQCjd1JDWZFsUTG9E6IH9k qS3k8aoN59Y9vhtTC0TkfWLlfLsIp4AYrykijUuKv3U9UkSl/tAjKn6au42V/dbzaBne4 C3kkMxLiB4gFVOV+JY6GRivkQMfGNEcNn55Cd8Xo+97VWpb8LxMjFrKDV2BgeiKmi61yX r2KnKJ+DnQo3lE5CKmic0Q0Hsgn8VNYynfHxgGfssQJV4nLWoqD85mZdM/ZOSztblPQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792639323; h=DMARC-Filter:X-UUID:DKIM-Signature:X-CID-P-RULE:X-CID-O-INFO: X-CID-META:X-CID-BVR:X-CID-BAS:X-CID-FACTOR:X-CID-RHF:X-UUID:Received: Received:Received:From:To:CC:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding: Content-Type; bh=ukBlyrJcHZ8wooJPB4T4DOALOZGDMzYKGvxePLMSU0I=; b=W0Jc+EGy6vO3lRcLM7o7uhLlMjvOcmKDC0vlY21mwQ81357/F2rBpfRCTFElkHUDZqgB pydmb6z+ZG/Oqcwm6i9cFsoRB48EQe1IEFzuNOuJ6YbQspL6Tf4yzXAbuNPD+6aim1Kn+ VeZKHZsWYqVdhxi13oZXeXtTzdqwCELZghNIoAHzkvZdmIhdQO4cfl2d1HdcJAKhx6Nxy u173LwYRd3SFlBwf2EIhQq7+NpaCCB/RLjmfcwqEJkCyD52k3YRVnc15F8Hb53uMo+yZo 8I7GD3jV0L0+5HO1C/Us8z7QNaUaZ+uasWkIIA/aCzqlqGtuAEa793+uhx4ROnxDCsw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass header.d=mediatek.com header.i=@mediatek.com header.a=rsa-sha256 header.s=dk header.b=h2Uv60ql; arc=none smtp.remote-ip=210.61.82.184 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76825606A31E; Thu, 22 Oct 2026 03:22:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 76825606A31E 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, unprotected) header.d=mediatek.com header.i=@mediatek.com header.a=rsa-sha256 header.s=dk header.b=h2Uv60ql X-UUID: baad77cecdc711f18dc8c9802ae25ab1-20261022 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=ukBlyrJcHZ8wooJPB4T4DOALOZGDMzYKGvxePLMSU0I=; b=h2Uv60qlSArBwqu2zxaSA2/VYHUfqWki5P253kFr+PhDwvNc4DTrNLokhkp2PdTQDp5Qpfu1jlV5UIUYKtG6TpUSBugCBFWNoOWgsNhonZ5ekPALW3wEs7stBgFtlkfQKWc/BYAkTTKwF7gMMUXp4fsHbXyLc106AAFNFLHiksI=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.20,REQID:0d725283-924e-4bfc-afc4-adf9bf25b13f,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:291e20b,CLOUDID:d7224cce-02bc-447e-ab88-2baec399874a,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: baad77cecdc711f18dc8c9802ae25ab1-20261022 Received: from mtkmbs14n1.mediatek.inc [(172.21.101.75)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1327272911; Thu, 22 Oct 2026 11:21:53 +0800 Received: from mtkmbs13n1.mediatek.inc (172.21.101.193) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Thu, 22 Oct 2026 11:21:52 +0800 Received: from mtksitap99.mediatek.inc (10.233.130.16) by mtkmbs13n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Thu, 22 Oct 2026 11:21:52 +0800 From: Chris Lu To: Marcel Holtmann , Johan Hedberg , Luiz Von Dentz CC: Hao Qin , Wenlong Tian , Sean Wang , Will Lee , SS Wu , linux-bluetooth , linux-kernel , linux-mediatek , Chris Lu Subject: [PATCH v4 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding Date: Thu, 22 Oct 2026 11:21:48 +0800 Message-ID: <20261022032150.2213479-2-chris.lu@mediatek.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20261022032150.2213479-1-chris.lu@mediatek.com> References: <20261022032150.2213479-1-chris.lu@mediatek.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain The ISO interrupt IN endpoint delivers a fixed-size transfer that holds one HCI ISO packet and zero-fills the remainder. That padding belongs to the transfer rather than to the stream, so it has to be dropped instead of reported to the host. btmtk_recv_isopkt() keeps parsing it: the zero bytes read as an ISO header with handle 0 and a Data_Total_Length of zero, and each one is passed to hci_recv_frame() as a complete frame. A single transfer yields a long run of them, which is what fills the HCI log with malformed ISO packets, and iso_recv() drops the SDU it is reassembling whenever handle 0 belongs to a live CIS/BIS. A zero Data_Total_Length carries no ISO Data Load, so such a packet is never part of the stream. Check for the zero-filled remainder before starting to parse the next frame, rather than after assembling a 4-byte header: a remainder shorter than HCI_ISO_HDR_SIZE would otherwise be held across calls as a partial header, corrupting the next transfer's framing. This also means a fully zero-filled remainder no longer costs an skb allocation that gets immediately freed. Reaching a zero Data_Total_Length any other way is then a genuine error, not padding. This was observed on MT7925, but btmtk_recv_isopkt() is shared by every MediaTek USB controller that supports ISO data. Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Co-developed-by: Hao Qin Signed-off-by: Hao Qin Co-developed-by: Wenlong Tian Signed-off-by: Wenlong Tian Signed-off-by: Chris Lu --- drivers/bluetooth/btmtk.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c index 75483d8230e1..01d5ad2479f4 100644 --- a/drivers/bluetooth/btmtk.c +++ b/drivers/bluetooth/btmtk.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include @@ -1565,6 +1566,14 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count) int len; if (!skb) { + /* Drop the endpoint's zero-filled padding before + * allocating an skb for it; a zero Data_Total_Length + * check below would miss a padding remainder + * shorter than an ISO header. + */ + if (mem_is_zero(buffer, count)) + break; + skb = bt_skb_alloc(HCI_MAX_ISO_SIZE, GFP_ATOMIC); if (!skb) { err = -ENOMEM; @@ -1588,6 +1597,17 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count) /* Complete ISO header */ hci_skb_expect(skb) = __le16_to_cpu(dlen); + if (!hci_skb_expect(skb)) { + /* Zero padding was ruled out above, so a + * zero Data_Total_Length here is invalid. + */ + kfree_skb(skb); + skb = NULL; + + err = -EILSEQ; + break; + } + if (skb_tailroom(skb) < hci_skb_expect(skb)) { kfree_skb(skb); skb = NULL; -- 2.45.2