From: Pauli Virtanen <pav@iki.fi>
To: linux-bluetooth@vger.kernel.org
Cc: Pauli Virtanen <pav@iki.fi>,
marcel@holtmann.org, luiz.dentz@gmail.com,
linux-mediatek@lists.infradead.org, chris.lu@mediatek.com
Subject: [PATCH v2] Bluetooth: btmtk: don't generate bogus ISO packets from zero padding
Date: Sat, 25 Apr 2026 15:55:31 +0300 [thread overview]
Message-ID: <621d8a2b651aba8e3c2197017ca94f06ec77b824.1777121590.git.pav@iki.fi> (raw)
With MT7925, received URBs for ISO have urb->actual_length of
MTK_ISO_THRESHOLD (264) and contain ISO packet data followed by zero
padding.
btmtk driver ISO handling added in commit ceac1cb0259d ("Bluetooth:
btusb: mediatek: add ISO data transmission functions") assumes the data
contains only payload, and generates bogus packets to hci_core from the
padding, resulting to printk errors "Bluetooth: hci0: ISO packet for
unknown connection handle 0"
Add check in btmtk that a new packet is not started if we have only
trailing zeros left in the URB. If so, skip them and emit an error once
per hdev, since this doesn't seem to be the intended behavior. This
reduces spam to user logs.
Limit this behavior to the 7925 model.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
---
Notes:
v2:
- limit this to the 7925 model, as that is the only one tested
If there's confirmation from Mediatek the zero padding instead of short
USB read is intentional, the warning is not needed.
drivers/bluetooth/btmtk.c | 35 +++++++++++++++++++++++++++++++++++
drivers/bluetooth/btmtk.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index ab34f1dd42bc..934daf004dd6 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1088,11 +1088,34 @@ struct urb *alloc_mtk_intr_urb(struct hci_dev *hdev, struct sk_buff *skb,
}
EXPORT_SYMBOL_GPL(alloc_mtk_intr_urb);
+static bool check_isopkt(struct hci_dev *hdev, void *buffer, int count,
+ int pktsize)
+{
+ struct btmtk_data *btmtk_data = hci_get_priv(hdev);
+
+ /* With MT7925 we receive URBs that have size MTK_ISO_THRESHOLD, with
+ * trailing zero padding following the ISO packet data. This appears not
+ * intentional, so flag an error, and skip rest of the URB to not
+ * generate ISO packets from the padding.
+ */
+ if (btmtk_data->isopkt_rx_pad && pktsize == MTK_ISO_THRESHOLD &&
+ count < pktsize && mem_is_zero(buffer, count)) {
+ if (!btmtk_data->isopkt_padding_seen) {
+ btmtk_data->isopkt_padding_seen = true;
+ bt_dev_err(hdev, "Zero ISO data (only first reported)");
+ }
+ return false;
+ }
+
+ return true;
+}
+
static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
{
struct btmtk_data *btmtk_data = hci_get_priv(hdev);
struct sk_buff *skb;
unsigned long flags;
+ int pktsize = count;
int err = 0;
spin_lock_irqsave(&btmtk_data->isorxlock, flags);
@@ -1102,6 +1125,9 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
int len;
if (!skb) {
+ if (!check_isopkt(hdev, buffer, count, pktsize))
+ break;
+
skb = bt_skb_alloc(HCI_MAX_ISO_SIZE, GFP_ATOMIC);
if (!skb) {
err = -ENOMEM;
@@ -1250,6 +1276,15 @@ static int btmtk_usb_isointf_init(struct hci_dev *hdev)
spin_lock_init(&btmtk_data->isorxlock);
+ switch (btmtk_data->dev_id) {
+ case 0x7925:
+ btmtk_data->isopkt_rx_pad = true;
+ break;
+ default:
+ btmtk_data->isopkt_rx_pad = false;
+ break;
+ }
+
__set_mtk_intr_interface(hdev);
err = btmtk_submit_intr_urb(hdev, GFP_KERNEL);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index c83c24897c95..bd97e37afd99 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -177,6 +177,8 @@ struct btmtk_data {
struct usb_interface *isopkt_intf;
struct usb_anchor isopkt_anchor;
struct sk_buff *isopkt_skb;
+ bool isopkt_rx_pad;
+ bool isopkt_padding_seen;
/* spinlock for ISO data transmission */
spinlock_t isorxlock;
--
2.53.0
reply other threads:[~2026-04-25 12:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=621d8a2b651aba8e3c2197017ca94f06ec77b824.1777121590.git.pav@iki.fi \
--to=pav@iki.fi \
--cc=chris.lu@mediatek.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).