[PATCH v3 RESEND 0/3] Bluetooth: btmtk: fix ISO data reception

[PATCH v3 RESEND 0/3] Bluetooth: btmtk: fix ISO data reception

[Chris Lu]

Resend due to rebase: the base this series was previously posted against
no longer exists in bluetooth-next's history, which is why it failed to
apply. Rebased onto current bluetooth-next; no content changes from v3.

Two fixes for btmtk_recv_isopkt(), found while debugging LE Audio on
MT7925, plus an update to the ISO data transmission setting. The function
is shared by every MediaTek USB controller that supports ISO data, so none
of this is specific to that part.

Patch 1 drops the zero padding that the ISO interrupt IN endpoint appends
to each transfer instead of parsing it as ISO packets.

Patch 2 bounds Data_Total_Length by hdev->iso_mtu.

Patch 3 updates the mt79xx ISO data transmission setting.

The three hunks do not overlap, so any prefix of the series applies on its
own.

Changes in v3 RESEND:
- Resend due to rebase. No content changes.

Changes in v3:
- Patch 1: instead of dropping a packet solely because Data_Total_Length
  is zero, also confirm that the rest of the transfer is zero-filled
  before treating it as padding.
- Patch 2, 3: unchanged.

Changes in v2:
- Patch 2 reworked and retitled.
- Patch 3 added.

Based on bluetooth-next.

Chris Lu (3):
  Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding
  Bluetooth: btmtk: bound the ISO payload length by the controller's MTU
  Bluetooth: btmtk: derive the firmware ISO setting from
    MTK_ISO_THRESHOLD

 drivers/bluetooth/btmtk.c | 44 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 39 insertions(+), 5 deletions(-)

-- 
2.45.2

[PATCH v3 RESEND 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding

[Chris Lu]

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. Confirm that the rest of the transfer is
zero-filled before dropping it, since the padding runs to the end of the
transfer.

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..90463208385b 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>
@@ -1588,6 +1589,25 @@ 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)) {
+				/* The interrupt endpoint zero-fills the
+				 * remainder of the transfer after the one
+				 * packet it carries. Confirm that is what
+				 * this is before dropping it.
+				 */
+				if (!mem_is_zero(buffer, count)) {
+					kfree_skb(skb);
+					skb = NULL;
+
+					err = -EILSEQ;
+					break;
+				}
+
+				kfree_skb(skb);
+				skb = NULL;
+				break;
+			}
+
 			if (skb_tailroom(skb) < hci_skb_expect(skb)) {
 				kfree_skb(skb);
 				skb = NULL;
-- 
2.45.2

RE: Bluetooth: btmtk: fix ISO data reception

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1190327/

---Test result---

Test Summary:
CheckPatch                    PASS      1.58 seconds
VerifyFixes                   PASS      0.09 seconds
VerifySignedoff               PASS      0.09 seconds
GitLint                       FAIL      0.71 seconds
SubjectPrefix                 PASS      0.25 seconds
BuildKernel                   PASS      21.70 seconds
CheckAllWarning               PASS      25.46 seconds
CheckSparse                   PASS      28.31 seconds
BuildKernel32                 PASS      22.39 seconds
CheckKernelLLVM               PASS      25.79 seconds
TestRunnerSetup               PASS      518.28 seconds
IncrementalBuild              PASS      28.67 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3,RESEND,1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding

1: T1 Title exceeds max length (84>80): "[v3,RESEND,1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding"
[v3,RESEND,2/3] Bluetooth: btmtk: bound the ISO payload length by the controller's MTU

1: T1 Title exceeds max length (86>80): "[v3,RESEND,2/3] Bluetooth: btmtk: bound the ISO payload length by the controller's MTU"
[v3,RESEND,3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD

1: T1 Title exceeds max length (88>80): "[v3,RESEND,3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD"


https://github.com/bluez/bluetooth-next/pull/971

---
Regards,
Linux Bluetooth

[PATCH v3 RESEND 2/3] Bluetooth: btmtk: bound the ISO payload length by the controller's MTU

[Chris Lu]

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 90463208385b..479f3d937554 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1557,8 +1557,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;
 
@@ -1566,7 +1573,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;
@@ -1608,7 +1616,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

[PATCH v3 RESEND 3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD

[Chris Lu]

The ISO data transfer size is spelled out twice: as a raw byte pair in the
vendor command sent by btmtk_usb_isointf_init(), and as MTK_ISO_THRESHOLD
for the padding in btmtk_isopkt_pad(). Build the command payload from the
macro so the size is stated once, and update the setting for current
MediaTek controllers.

Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions")
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
---
 drivers/bluetooth/btmtk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 479f3d937554..0f632240d991 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -31,7 +31,7 @@
 #define BTMTK_CBMCU_FLAG_ENABLE_PATCH	0xF1
 
 /* It is for mt79xx iso data transmission setting */
-#define MTK_ISO_THRESHOLD	264
+#define MTK_ISO_THRESHOLD	342
 
 struct btmtk_patch_header {
 	u8 datetime[16];
@@ -1741,7 +1741,7 @@ static int btmtk_submit_intr_urb(struct hci_dev *hdev, gfp_t mem_flags)
 static int btmtk_usb_isointf_init(struct hci_dev *hdev)
 {
 	struct btmtk_data *btmtk_data = hci_get_priv(hdev);
-	u8 iso_param[2] = { 0x08, 0x01 };
+	__le16 iso_param = cpu_to_le16(MTK_ISO_THRESHOLD);
 	struct sk_buff *skb;
 	int err;
 
@@ -1756,7 +1756,7 @@ static int btmtk_usb_isointf_init(struct hci_dev *hdev)
 		return err;
 	}
 
-	skb = __hci_cmd_sync(hdev, 0xfd98, sizeof(iso_param), iso_param,
+	skb = __hci_cmd_sync(hdev, 0xfd98, sizeof(iso_param), &iso_param,
 			     HCI_INIT_TIMEOUT);
 	if (IS_ERR(skb)) {
 		bt_dev_err(hdev, "Failed to apply iso setting (%ld)", PTR_ERR(skb));
-- 
2.45.2

Re: [PATCH v3 RESEND 0/3] Bluetooth: btmtk: fix ISO data reception

[Luiz Augusto von Dentz]

Hi Chris,

On Wed, Oct 21, 2026 at 4:43 AM Chris Lu <chris.lu@mediatek.com> wrote:
>
> Resend due to rebase: the base this series was previously posted against
> no longer exists in bluetooth-next's history, which is why it failed to
> apply. Rebased onto current bluetooth-next; no content changes from v3.
>
> Two fixes for btmtk_recv_isopkt(), found while debugging LE Audio on
> MT7925, plus an update to the ISO data transmission setting. The function
> is shared by every MediaTek USB controller that supports ISO data, so none
> of this is specific to that part.
>
> Patch 1 drops the zero padding that the ISO interrupt IN endpoint appends
> to each transfer instead of parsing it as ISO packets.
>
> Patch 2 bounds Data_Total_Length by hdev->iso_mtu.
>
> Patch 3 updates the mt79xx ISO data transmission setting.
>
> The three hunks do not overlap, so any prefix of the series applies on its
> own.
>
> Changes in v3 RESEND:
> - Resend due to rebase. No content changes.
>
> Changes in v3:
> - Patch 1: instead of dropping a packet solely because Data_Total_Length
>   is zero, also confirm that the rest of the transfer is zero-filled
>   before treating it as padding.
> - Patch 2, 3: unchanged.
>
> Changes in v2:
> - Patch 2 reworked and retitled.
> - Patch 3 added.
>
> Based on bluetooth-next.
>
> Chris Lu (3):
>   Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding
>   Bluetooth: btmtk: bound the ISO payload length by the controller's MTU
>   Bluetooth: btmtk: derive the firmware ISO setting from
>     MTK_ISO_THRESHOLD
>
>  drivers/bluetooth/btmtk.c | 44 ++++++++++++++++++++++++++++++++++-----
>  1 file changed, 39 insertions(+), 5 deletions(-)
>
> --
> 2.45.2
>

Sashiko is still flagging a problem:

https://sashiko.dev/#/patchset/20261021084337.1515468-1-chris.lu%40mediatek.com

-- 
Luiz Augusto von Dentz

Re: [PATCH v3 RESEND 0/3] Bluetooth: btmtk: fix ISO data reception

[Chris Lu (陸稚泓)]

Hi Luiz,

Thanks for the reminder, I've noticed the results of Sashiko's review.

On Wed, 2026-10-21 at 10:23 -0400, Luiz Augusto von Dentz wrote:
> Hi Chris,
> 
> On Wed, Oct 21, 2026 at 4:43 AM Chris Lu <chris.lu@mediatek.com>
> wrote:
> > 
> > Resend due to rebase: the base this series was previously posted
> > against
> > no longer exists in bluetooth-next's history, which is why it
> > failed to
> > apply. Rebased onto current bluetooth-next; no content changes from
> > v3.
> > 
> > Two fixes for btmtk_recv_isopkt(), found while debugging LE Audio
> > on
> > MT7925, plus an update to the ISO data transmission setting. The
> > function
> > is shared by every MediaTek USB controller that supports ISO data,
> > so none
> > of this is specific to that part.
> > 
> > Patch 1 drops the zero padding that the ISO interrupt IN endpoint
> > appends
> > to each transfer instead of parsing it as ISO packets.
> > 
> > Patch 2 bounds Data_Total_Length by hdev->iso_mtu.
> > 
> > Patch 3 updates the mt79xx ISO data transmission setting.
> > 
> > The three hunks do not overlap, so any prefix of the series applies
> > on its
> > own.
> > 
> > Changes in v3 RESEND:
> > - Resend due to rebase. No content changes.
> > 
> > Changes in v3:
> > - Patch 1: instead of dropping a packet solely because
> > Data_Total_Length
> >   is zero, also confirm that the rest of the transfer is zero-
> > filled
> >   before treating it as padding.
> > - Patch 2, 3: unchanged.
> > 
> > Changes in v2:
> > - Patch 2 reworked and retitled.
> > - Patch 3 added.
> > 
> > Based on bluetooth-next.
> > 
> > Chris Lu (3):
> >   Bluetooth: btmtk: drop zero-length ISO packets from endpoint
> > padding
> >   Bluetooth: btmtk: bound the ISO payload length by the
> > controller's MTU
> >   Bluetooth: btmtk: derive the firmware ISO setting from
> >     MTK_ISO_THRESHOLD
> > 
> >  drivers/bluetooth/btmtk.c | 44 ++++++++++++++++++++++++++++++++++-
> > ----
> >  1 file changed, 39 insertions(+), 5 deletions(-)
> > 
> > --
> > 2.45.2
> > 
> 
> Sashiko is still flagging a problem:
> 
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20261021084337.1515468-1-chris.lu*40mediatek.com__;IyU!!CTRNKA9wMg0ARbw!heJ4Q7JNUGP7kU0I1b-VYacWXQtYzXNUNhsuWVeqBSzOyMw8rIeqJ_WJV187h0noHUi3xzGLwHGlcvWmCIA$
>  
> 

I'll send the next version after confirming my fix is effective and all
basic functions work normally.

Thanks,
Chris Lu

[PATCH v4 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding

[Chris Lu]

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

RE: Bluetooth: btmtk: fix ISO data reception

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1190983/

---Test result---

Test Summary:
CheckPatch                    PASS      3.43 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.14 seconds
GitLint                       FAIL      1.03 seconds
SubjectPrefix                 PASS      0.39 seconds
BuildKernel                   PASS      29.28 seconds
CheckAllWarning               PASS      34.10 seconds
CheckSparse                   PASS      36.96 seconds
BuildKernel32                 PASS      29.51 seconds
CheckKernelLLVM               PASS      35.31 seconds
TestRunnerSetup               PASS      708.58 seconds
IncrementalBuild              PASS      32.69 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v4,3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD

1: T1 Title exceeds max length (81>80): "[v4,3/3] Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD"


https://github.com/bluez/bluetooth-next/pull/976

---
Regards,
Linux Bluetooth

[PATCH v2 1/3] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding

[Chris Lu]

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. The padding runs to the end of the transfer, so
stop parsing once one is seen.

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 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index bdc85147b97f..869eb2176379 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1201,6 +1201,19 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
 			/* Complete ISO header */
 			hci_skb_expect(skb) = __le16_to_cpu(dlen);
 
+			/* The interrupt endpoint zero-fills the remainder of
+			 * each transfer, and that padding parses as a header
+			 * with a zero Data_Total_Length. Such a packet carries
+			 * no ISO Data Load at all and is never emitted by the
+			 * controller, so stop parsing here rather than hand a
+			 * bogus handle 0 packet to the stack.
+			 */
+			if (!hci_skb_expect(skb)) {
+				kfree_skb(skb);
+				skb = NULL;
+				break;
+			}
+
 			if (skb_tailroom(skb) < hci_skb_expect(skb)) {
 				kfree_skb(skb);
 				skb = NULL;
-- 
2.45.2

RE: Bluetooth: btmtk: fix ISO data reception

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: drivers/bluetooth/btmtk.c:24
error: drivers/bluetooth/btmtk.c: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth

[PATCH 1/2] Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding

[Chris Lu]

The ISO interrupt IN endpoint delivers one HCI ISO packet per 264-byte
transfer and zero-fills the remainder. btmtk_recv_isopkt() keeps parsing
that padding: every four zero bytes look like an ISO header with handle 0
and Data_Total_Length 0, and are passed to hci_recv_frame() as a complete
frame. A single transfer can inject up to 64 of them, which is what fills
the HCI log with malformed ISO packets. If handle 0 belongs to a live
CIS/BIS, iso_recv() also drops the SDU it is reassembling.

A zero Data_Total_Length carries no ISO Data Load at all, and the
controller never emits one -- these are produced purely by parsing the
padding. The padding always runs to the end of the transfer, so stop
parsing once one is seen.

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 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index bdc85147b97f..869eb2176379 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1201,6 +1201,19 @@ static int btmtk_recv_isopkt(struct hci_dev *hdev, void *buffer, int count)
 			/* Complete ISO header */
 			hci_skb_expect(skb) = __le16_to_cpu(dlen);
 
+			/* The interrupt endpoint zero-fills the remainder of
+			 * each transfer, and that padding parses as a header
+			 * with a zero Data_Total_Length. Such a packet carries
+			 * no ISO Data Load at all and is never emitted by the
+			 * controller, so stop parsing here rather than hand a
+			 * bogus handle 0 packet to the stack.
+			 */
+			if (!hci_skb_expect(skb)) {
+				kfree_skb(skb);
+				skb = NULL;
+				break;
+			}
+
 			if (skb_tailroom(skb) < hci_skb_expect(skb)) {
 				kfree_skb(skb);
 				skb = NULL;
-- 
2.45.2

RE: Bluetooth: btmtk: fix ISO data reception

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1184506/

---Test result---

Test Summary:
CheckPatch                    PASS      1.34 seconds
VerifyFixes                   PASS      0.11 seconds
VerifySignedoff               PASS      0.11 seconds
GitLint                       PASS      0.59 seconds
SubjectPrefix                 PASS      0.20 seconds
BuildKernel                   PASS      27.73 seconds
CheckAllWarning               PASS      31.68 seconds
CheckSparse                   PASS      34.89 seconds
BuildKernel32                 PASS      28.14 seconds
CheckKernelLLVM               PASS      31.53 seconds
TestRunnerSetup               PASS      653.17 seconds
IncrementalBuild              PASS      28.03 seconds



https://github.com/bluez/bluetooth-next/pull/913

---
Regards,
Linux Bluetooth