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 v2 2/3] Bluetooth: btmtk: bound the ISO payload length by the controller's MTU
Date: Thu, 15 Oct 2026 16:14:49 +0800 [thread overview]
Message-ID: <20261015081450.1241194-3-chris.lu@mediatek.com> (raw)
In-Reply-To: <20261015081450.1241194-1-chris.lu@mediatek.com>
btmtk_recv_isopkt() bounds the Data_Total_Length reported by the
controller with skb_tailroom(skb) < hci_skb_expect(skb). That keeps the
reassembly inside the skb, but it enforces no protocol limit: the head
allocation is rounded up to the next kmalloc bucket and skb_tailroom()
reports what the bucket can hold rather than what was requested, which is
several hundred bytes more. An oversized length therefore passes, and the
parser keeps pulling bytes out of the following transfers to fill it,
swallowing the real ISO packets they carry until the frame is handed to
hci_recv_frame().
The controller reports the largest ISO_Data_Packet_Length it will send in
LE Read Buffer Size [v2], which hci_cc_le_read_buffer_size_v2() keeps in
hdev->iso_mtu. Once that is available, bound the length by it and size the
receive skb to hold that much plus the 4-byte header. HCI_MAX_ISO_SIZE is
kept only as a fallback for the window before the command completes.
Keep the skb_tailroom() test as well, because a fragment started before
hdev->iso_mtu was populated sits in an skb sized for the fallback.
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 | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 869eb2176379..7c3fffcefdf1 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1169,8 +1169,15 @@ 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;
+ unsigned int iso_mtu;
int err = 0;
+ /* The controller reports the largest Data_Total_Length it will send in
+ * LE Read Buffer Size [v2]. Fall back to HCI_MAX_ISO_SIZE while that
+ * command has not completed yet.
+ */
+ iso_mtu = hdev->iso_mtu ? hdev->iso_mtu : HCI_MAX_ISO_SIZE;
+
spin_lock_irqsave(&btmtk_data->isorxlock, flags);
skb = btmtk_data->isopkt_skb;
@@ -1178,7 +1185,8 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
int len;
if (!skb) {
- skb = bt_skb_alloc(HCI_MAX_ISO_SIZE, GFP_ATOMIC);
+ skb = bt_skb_alloc(HCI_ISO_HDR_SIZE + iso_mtu,
+ GFP_ATOMIC);
if (!skb) {
err = -ENOMEM;
break;
@@ -1214,7 +1222,13 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
break;
}
- if (skb_tailroom(skb) < hci_skb_expect(skb)) {
+ /* Reject a length the controller said it would never
+ * send. The skb_tailroom() test is kept because a
+ * fragment started before hdev->iso_mtu was populated
+ * sits in a smaller skb than iso_mtu now allows.
+ */
+ if (hci_skb_expect(skb) > iso_mtu ||
+ skb_tailroom(skb) < hci_skb_expect(skb)) {
kfree_skb(skb);
skb = NULL;
--
2.45.2
next prev parent reply other threads:[~2026-10-15 8:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 8:14 [PATCH v2 0/3] Bluetooth: btmtk: fix ISO data reception Chris Lu
2026-10-15 8:14 ` [PATCH v2 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding Chris Lu
2026-10-15 12:09 ` Bluetooth: btmtk: fix ISO data reception bluez.test.bot
2026-10-15 8:14 ` Chris Lu [this message]
2026-10-15 8:14 ` [PATCH v2 3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD Chris Lu
2026-10-15 13:47 ` [PATCH v2 0/3] Bluetooth: btmtk: fix ISO data reception Luiz Augusto von Dentz
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=20261015081450.1241194-3-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