From: Chris Lu <chris.lu@mediatek.com>
To: Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Luiz Von Dentz <luiz.dentz@gmail.com>
Cc: Hao Qin <hao.qin@mediatek.com>,
Wenlong Tian <ot_wenlong.tian@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>,
Will Lee <will-cy.Lee@mediatek.com>, SS Wu <ss.wu@mediatek.com>,
linux-bluetooth <linux-bluetooth@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mediatek <linux-mediatek@lists.infradead.org>,
Chris Lu <chris.lu@mediatek.com>
Subject: [PATCH v4 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding
Date: Thu, 22 Oct 2026 11:21:48 +0800 [thread overview]
Message-ID: <20261022032150.2213479-2-chris.lu@mediatek.com> (raw)
In-Reply-To: <20261022032150.2213479-1-chris.lu@mediatek.com>
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 <hao.qin@mediatek.com>
Signed-off-by: Hao Qin <hao.qin@mediatek.com>
Co-developed-by: Wenlong Tian <ot_wenlong.tian@mediatek.com>
Signed-off-by: Wenlong Tian <ot_wenlong.tian@mediatek.com>
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
---
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 <linux/usb.h>
#include <linux/iopoll.h>
#include <linux/overflow.h>
+#include <linux/string.h>
#include <linux/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -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
next prev parent reply other threads:[~2026-10-22 3:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 3:21 [PATCH v4 0/3] Bluetooth: btmtk: fix ISO data reception Chris Lu
2026-10-22 3:21 ` Chris Lu [this message]
2026-10-22 3:21 ` [PATCH v4 2/3] Bluetooth: btmtk: bound the ISO payload length by the controller's MTU Chris Lu
2026-10-22 3:21 ` [PATCH v4 3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD Chris Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261022032150.2213479-2-chris.lu@mediatek.com \
--to=chris.lu@mediatek.com \
--cc=hao.qin@mediatek.com \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=ot_wenlong.tian@mediatek.com \
--cc=sean.wang@mediatek.com \
--cc=ss.wu@mediatek.com \
--cc=will-cy.Lee@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®