[PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop

pip-izony

author

2025-10-07 23:38 UTC #0 lore raw

PATCH 1/1 Bluetooth: bfusb: Fix buffer over-read in rx processing loop

The bfusb_rx_complete() function parses incoming URB data in while loop. The logic does not sufficiently validate the remaining buffer size(count) accross loop iterations, which can lead to a buffer over-read.

For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Seungjin Bae <[email protected]>

---
 drivers/bluetooth/bfusb.c | 4 ++++
 1 file changed, 4 insertions(+)

drivers/bluetooth/bfusb.c +4 -0

index 8df310983bf6..f17eae6dbd7d 100644
@@ -360,6 +360,10 @@ static void bfusb_rx_complete(struct urb *urb)
 			count -= 2;
 			buf   += 2;
 		} else {
+            if (count < 3) {
+                bf_dev_err(data->hdev, "block header is too short");
+                break;
+            }
 			len = (buf[2] == 0) ? 256 : buf[2];
 			count -= 3;
 			buf   += 3;

Signature · 1 line

2.43.0

[email protected]

2025-10-08 01:17 UTC #1 lore raw

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/project/bluetooth/list/?series=1009216

---Test result---

Test Summary:

CheckPatch                    PENDING   0.32 seconds
GitLint                       PENDING   0.30 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   FAIL      21.89 seconds
CheckAllWarning               FAIL      23.99 seconds
CheckSparse                   FAIL      27.44 seconds
BuildKernel32                 FAIL      21.83 seconds
TestRunnerSetup               FAIL      470.92 seconds
TestRunner_l2cap-tester       FAIL      0.11 seconds
TestRunner_iso-tester         FAIL      0.11 seconds
TestRunner_bnep-tester        FAIL      0.11 seconds
TestRunner_mgmt-tester        FAIL      0.11 seconds
TestRunner_rfcomm-tester      FAIL      0.11 seconds
TestRunner_sco-tester         FAIL      0.11 seconds
TestRunner_ioctl-tester       FAIL      0.12 seconds
TestRunner_mesh-tester        FAIL      0.11 seconds
TestRunner_smp-tester         FAIL      0.11 seconds
TestRunner_userchan-tester    FAIL      0.11 seconds
IncrementalBuild              PENDING   0.78 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: BuildKernel - FAIL
Desc: Build Kernel for Bluetooth
Output:

drivers/bluetooth/bfusb.c: In function ‘bfusb_rx_complete’:
drivers/bluetooth/bfusb.c:364:17: error: implicit declaration of function ‘bf_dev_err’; did you mean ‘bt_dev_err’? [-Werror=implicit-function-declaration]

  364 |                 bf_dev_err(data->hdev, "block header is too short");
      |                 ^~~~~~~~~~
      |                 bt_dev_err

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:287: drivers/bluetooth/bfusb.o] Error 1 make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:556: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:556: drivers] Error 2 make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/github/workspace/src/src/Makefile:2011: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
##############################
Test: CheckAllWarning - FAIL
Desc: Run linux kernel with all warning enabled
Output:

drivers/bluetooth/bfusb.c: In function ‘bfusb_rx_complete’:
drivers/bluetooth/bfusb.c:364:17: error: implicit declaration of function ‘bf_dev_err’; did you mean ‘bt_dev_err’? [-Werror=implicit-function-declaration]

  364 |                 bf_dev_err(data->hdev, "block header is too short");
      |                 ^~~~~~~~~~
      |                 bt_dev_err

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:287: drivers/bluetooth/bfusb.o] Error 1 make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:556: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:556: drivers] Error 2 make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/github/workspace/src/src/Makefile:2011: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
##############################
Test: CheckSparse - FAIL
Desc: Run sparse tool with linux kernel
Output:

net/bluetooth/af_bluetooth.c:248:25: warning: context imbalance in 'bt_accept_enqueue' - different lock contexts for basic block
net/bluetooth/hci_core.c:85:9: warning: context imbalance in '__hci_dev_get' - different lock contexts for basic block
net/bluetooth/hci_core.c: note: in included file (through include/linux/notifier.h, include/linux/memory_hotplug.h, include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, include/linux/radix-tree.h, ...):
./include/linux/srcu.h:373:9: warning: context imbalance in 'hci_dev_put_srcu' - unexpected unlock
net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):
./include/net/bluetooth/hci.h:2659:47: warning: array of flexible structures
./include/net/bluetooth/hci.h:2745:43: warning: array of flexible structures
drivers/bluetooth/hci_ag6xx.c:257:24: warning: restricted __le32 degrades to integer
drivers/bluetooth/hci_mrvl.c:170:23: warning: restricted __le16 degrades to integer
drivers/bluetooth/hci_mrvl.c:203:23: warning: restricted __le16 degrades to integer
drivers/bluetooth/bfusb.c: In function ‘bfusb_rx_complete’:
drivers/bluetooth/bfusb.c:364:17: error: implicit declaration of function ‘bf_dev_err’; did you mean ‘bt_dev_err’? [-Werror=implicit-function-declaration]

  364 |                 bf_dev_err(data->hdev, "block header is too short");
      |                 ^~~~~~~~~~
      |                 bt_dev_err

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:287: drivers/bluetooth/bfusb.o] Error 1 make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:556: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:556: drivers] Error 2
make[2]: *** Waiting for unfinished jobs.... net/bluetooth/hci_codec.c: note: in included file:
./include/net/bluetooth/hci_core.h:153:35: warning: array of flexible structures net/bluetooth/sco.c: note: in included file:
./include/net/bluetooth/hci_core.h:153:35: warning: array of flexible structures make[1]: *** [/github/workspace/src/src/Makefile:2011: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
##############################
Test: BuildKernel32 - FAIL
Desc: Build 32bit Kernel for Bluetooth
Output:

drivers/bluetooth/bfusb.c: In function ‘bfusb_rx_complete’:
drivers/bluetooth/bfusb.c:364:17: error: implicit declaration of function ‘bf_dev_err’; did you mean ‘bt_dev_err’? [-Werror=implicit-function-declaration]

  364 |                 bf_dev_err(data->hdev, "block header is too short");
      |                 ^~~~~~~~~~
      |                 bt_dev_err

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:287: drivers/bluetooth/bfusb.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:556: drivers/bluetooth] Error 2
make[2]: *** [scripts/Makefile.build:556: drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/github/workspace/src/src/Makefile:2011: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
##############################
Test: TestRunnerSetup - FAIL
Desc: Setup kernel and bluez for test-runner
Output:
Kernel:
drivers/bluetooth/bfusb.c: In function ‘bfusb_rx_complete’:
drivers/bluetooth/bfusb.c:364:17: error: implicit declaration of function ‘bf_dev_err’; did you mean ‘bt_dev_err’? [-Werror=implicit-function-declaration]

  364 |                 bf_dev_err(data->hdev, "block header is too short");
      |                 ^~~~~~~~~~
      |                 bt_dev_err

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:287: drivers/bluetooth/bfusb.o] Error 1 make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:556: drivers/bluetooth] Error 2 make[3]: *** Waiting for unfinished jobs....
make[2]: *** [scripts/Makefile.build:556: drivers] Error 2 make[1]: *** [/github/workspace/src/src/Makefile:2011: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_iso-tester - FAIL
Desc: Run iso-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_bnep-tester - FAIL
Desc: Run bnep-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_rfcomm-tester - FAIL
Desc: Run rfcomm-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_ioctl-tester - FAIL
Desc: Run ioctl-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_smp-tester - FAIL
Desc: Run smp-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: TestRunner_userchan-tester - FAIL
Desc: Run userchan-tester with test-runner
Output:

Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator
qemu: could not open kernel file '/github/workspace/src/src/arch/x86/boot/bzImage': No such file or directory
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:

---
Regards,
Linux Bluetooth

pip-izony

author

2025-10-08 01:57 UTC #2 lore raw

PATCH v2 1/1 Bluetooth: bfusb: Fix buffer over-read in rx processing loop

In reply to pip-izony

From: Seungjin Bae <[email protected]>

The bfusb_rx_complete() function parses incoming URB data in while loop. The logic does not sufficiently validate the remaining buffer size(count) accross loop iterations, which can lead to a buffer over-read.

For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Seungjin Bae <[email protected]>

---
v1 -> v2: Fixing the error function name

 drivers/bluetooth/bfusb.c | 4 ++++
 1 file changed, 4 insertions(+)

drivers/bluetooth/bfusb.c +4 -0

index 8df310983bf6..45f4ec5b6860 100644
@@ -360,6 +360,10 @@ static void bfusb_rx_complete(struct urb *urb)
 			count -= 2;
 			buf   += 2;
 		} else {
+            if (count < 3) {
+                bt_dev_err(data->hdev, "block header is too short");
+                break;
+            }
 			len = (buf[2] == 0) ? 256 : buf[2];
 			count -= 3;
 			buf   += 3;

Signature · 1 line

2.43.0

[email protected]

2025-10-08 03:01 UTC #3 lore raw

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/project/bluetooth/list/?series=1009231

---Test result---

Test Summary:

CheckPatch                    PENDING   0.32 seconds
GitLint                       PENDING   0.23 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      25.24 seconds
CheckAllWarning               PASS      28.02 seconds
CheckSparse                   PASS      32.38 seconds
BuildKernel32                 PASS      25.47 seconds
TestRunnerSetup               PASS      499.51 seconds
TestRunner_l2cap-tester       PASS      24.60 seconds
TestRunner_iso-tester         PASS      72.40 seconds
TestRunner_bnep-tester        PASS      6.24 seconds
TestRunner_mgmt-tester        FAIL      124.47 seconds
TestRunner_rfcomm-tester      PASS      9.47 seconds
TestRunner_sco-tester         PASS      14.61 seconds
TestRunner_ioctl-tester       PASS      10.27 seconds
TestRunner_mesh-tester        FAIL      12.33 seconds
TestRunner_smp-tester         PASS      8.61 seconds
TestRunner_userchan-tester    PASS      6.55 seconds
IncrementalBuild              PENDING   0.83 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 490, Passed: 485 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success Failed 0.107 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    2.601 seconds
Mesh - Send cancel - 2                               Timed out    2.002 seconds

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:

---
Regards,
Linux Bluetooth

Paul Menzel

2025-10-08 03:52 UTC #4 lore raw

In reply to pip-izony

Dear Seungjin,

Thank you for the patch.

Am 08.10.25 um 03:56 schrieb pip-izony:

Quoted 3 lines

From: Seungjin Bae <[email protected]>
The bfusb_rx_complete() function parses incoming URB data in while loop.

… in *a* while loop.

Quoted 2 lines

The logic does not sufficiently validate the remaining buffer size(count) accross loop iterations, which can lead to a buffer over-read.

across

Quoted 4 lines

For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

Please re-flow for 75 characters per line.

Quoted 16 lines

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.
Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by Seungjin Bae <[email protected]>
---
v1 -> v2: Fixing the error function name
  drivers/bluetooth/bfusb.c | 4 ++++
  1 file changed, 4 insertions(+)
drivers/bluetooth/bfusb.c +0 -0
index 8df310983bf6..45f4ec5b6860 100644

drivers/bluetooth/bfusb.c static void bfusb_rx_complete(struct urb *urb) · line 364

Quoted 5 lines

drivers/bluetooth/bfusb.c +2 -0

@@ -360,6 +360,10 @@ static void bfusb_rx_complete(struct urb *urb)
  			count -= 2;
  			buf   += 2;
  		} else {
+            if (count < 3) {
+                bt_dev_err(data->hdev, "block header is too short");

Please print count and 3.

drivers/bluetooth/bfusb.c static void bfusb_rx_complete(struct urb *urb) · line 366

Quoted 2 lines

drivers/bluetooth/bfusb.c +2 -0

+                break;
+            }

Please use tabs for alignment. scripts/checkpatch.pl should have warned about this.

drivers/bluetooth/bfusb.c static void bfusb_rx_complete(struct urb *urb) · line 369

Quoted 3 lines

drivers/bluetooth/bfusb.c +0 -0

  			len = (buf[2] == 0) ? 256 : buf[2];
  			count -= 3;
  			buf   += 3;

Kind regards,

Paul

pip-izony

author

2025-10-09 02:57 UTC #5 lore raw

PATCH v3 1/1 Bluetooth: bfusb: Fix buffer over-read in rx processing loop

From: Seungjin Bae <[email protected]>

The bfusb_rx_complete() function parses incoming URB data in a while loop. The logic does not sufficiently validate the remaining buffer size(count) across loop iterations, which can lead to a buffer over-read.

For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Seungjin Bae <[email protected]>

---
v1 -> v2: Fixing the error function name
v2 -> v3: Addressing feedback from Paul Menzel

 drivers/bluetooth/bfusb.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/bluetooth/bfusb.c +6 -0

index 8df310983bf6..90ca5ab2acc3 100644
@@ -360,6 +360,12 @@ static void bfusb_rx_complete(struct urb *urb)
 			count -= 2;
 			buf   += 2;
 		} else {
+			if (count < 3) {
+				bt_dev_err(data->hdev,
+				       "block header is too short (count=%d, expected=3)",
+				       count);
+				break;
+			}
 			len = (buf[2] == 0) ? 256 : buf[2];
 			count -= 3;
 			buf   += 3;

Signature · 1 line

2.43.0

[email protected]

2025-10-09 03:50 UTC #6 lore raw

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/project/bluetooth/list/?series=1009568

---Test result---

Test Summary:

CheckPatch                    PENDING   0.40 seconds
GitLint                       PENDING   0.39 seconds
SubjectPrefix                 PASS      0.06 seconds
BuildKernel                   PASS      24.66 seconds
CheckAllWarning               PASS      27.33 seconds
CheckSparse                   PASS      30.77 seconds
BuildKernel32                 PASS      24.70 seconds
TestRunnerSetup               PASS      487.97 seconds
TestRunner_l2cap-tester       PASS      23.98 seconds
TestRunner_iso-tester         PASS      77.78 seconds
TestRunner_bnep-tester        PASS      6.79 seconds
TestRunner_mgmt-tester        FAIL      116.23 seconds
TestRunner_rfcomm-tester      PASS      9.30 seconds
TestRunner_sco-tester         PASS      14.38 seconds
TestRunner_ioctl-tester       PASS      9.90 seconds
TestRunner_mesh-tester        FAIL      11.45 seconds
TestRunner_smp-tester         PASS      8.46 seconds
TestRunner_userchan-tester    PASS      6.36 seconds
IncrementalBuild              PENDING   1.04 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 490, Passed: 485 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success Failed 0.108 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    1.818 seconds
Mesh - Send cancel - 2                               Timed out    1.996 seconds

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:

---
Regards,
Linux Bluetooth

Paul Menzel

Reviewed-by on v3 1/1

2025-10-09 07:01 UTC #7 lore raw

In reply to pip-izony

Dear Seungjin,

Thank you for the patch.

Am 09.10.25 um 04:57 schrieb pip-izony:

Quoted 29 lines

From: Seungjin Bae <[email protected]>
The bfusb_rx_complete() function parses incoming URB data in a while loop. The logic does not sufficiently validate the remaining buffer size(count) across loop iterations, which can lead to a buffer over-read.
For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.
This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.
Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by Seungjin Bae <[email protected]>
---
v1 -> v2: Fixing the error function name
v2 -> v3: Addressing feedback from Paul Menzel
  drivers/bluetooth/bfusb.c | 6 ++++++
  1 file changed, 6 insertions(+)
drivers/bluetooth/bfusb.c +0 -0
index 8df310983bf6..90ca5ab2acc3 100644

drivers/bluetooth/bfusb.c static void bfusb_rx_complete(struct urb *urb) · line 365

Quoted 6 lines

drivers/bluetooth/bfusb.c +3 -0

@@ -360,6 +360,12 @@ static void bfusb_rx_complete(struct urb *urb)
  			count -= 2;
  			buf   += 2;
  		} else {
+			if (count < 3) {
+				bt_dev_err(data->hdev,
+				       "block header is too short (count=%d, expected=3)",

Why not: block header count %d < 3 (too short)

drivers/bluetooth/bfusb.c static void bfusb_rx_complete(struct urb *urb) · line 371

Quoted 6 lines

drivers/bluetooth/bfusb.c +3 -0

+				       count);
+				break;
+			}
  			len = (buf[2] == 0) ? 256 : buf[2];
  			count -= 3;
  			buf   += 3;

Either way:

Reviewed-by Paul Menzel <[email protected]>

Kind regards,

Paul

pip-izony

author

2025-10-09 16:51 UTC #8 lore raw

PATCH v4 1/1 Bluetooth: bfusb: Fix buffer over-read in rx processing loop

From: Seungjin Bae <[email protected]>

The bfusb_rx_complete() function parses incoming URB data in a while loop. The logic does not sufficiently validate the remaining buffer size(count) across loop iterations, which can lead to a buffer over-read.

For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Seungjin Bae <[email protected]>

---
v1 -> v2: Fixing the error function name
v2 -> v3: Addressing feedback from Paul Menzel
v3 -> v4: Improving the error message for the block header count

 drivers/bluetooth/bfusb.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/bluetooth/bfusb.c +5 -0

index 8df310983bf6..02ba16775004 100644
@@ -360,6 +360,11 @@ static void bfusb_rx_complete(struct urb *urb)
 			count -= 2;
 			buf   += 2;
 		} else {
+			if (count < 3) {
+				bt_dev_err(data->hdev, "block header count %d < 3 (too short)",
+					   count);
+				break;
+			}
 			len = (buf[2] == 0) ? 256 : buf[2];
 			count -= 3;
 			buf   += 3;

Signature · 1 line

2.43.0

Luiz Augusto von Dentz

maintainer

2025-10-09 17:14 UTC #9 lore raw

Hi Pip-Izony,

Quoted 13 lines · pip-izony

From: Seungjin Bae <[email protected]>
The bfusb_rx_complete() function parses incoming URB data in a while loop. The logic does not sufficiently validate the remaining buffer size(count) across loop iterations, which can lead to a buffer over-read.
For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.

Quoted 5 lines

This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.
Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by Seungjin Bae <[email protected]>

This is sort of useless if you ask me, this driver is never used in practice, and even in case someone still have the only model it handles USB_DEVICE(0x057c, 0x2200) I bet it would have been easier to just add it to btusb since it appears to be using the standard class as well.

Quoted 27 lines

---
v1 -> v2: Fixing the error function name
v2 -> v3: Addressing feedback from Paul Menzel
v3 -> v4: Improving the error message for the block header count

 drivers/bluetooth/bfusb.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/bluetooth/bfusb.c +5 -1

index 8df310983bf6..02ba16775004 100644
@@ -360,6 +360,11 @@ static void bfusb_rx_complete(struct urb *urb)
                        count -= 2;
                        buf   += 2;
                } else {
+                       if (count < 3) {
+                               bt_dev_err(data->hdev, "block header count %d < 3 (too short)",
+                                          count);
+                               break;
+                       }
                        len = (buf[2] == 0) ? 256 : buf[2];
                        count -= 3;
                        buf   += 3;
--

2.43.0

Signature · 1 line

Luiz Augusto von Dentz

[email protected]

2025-10-09 17:34 UTC #10 lore raw

In reply to pip-izony

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/project/bluetooth/list/?series=1009817

---Test result---

Test Summary:

CheckPatch                    PENDING   0.31 seconds
GitLint                       PENDING   0.28 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      24.63 seconds
CheckAllWarning               PASS      27.40 seconds
CheckSparse                   PASS      31.09 seconds
BuildKernel32                 PASS      24.65 seconds
TestRunnerSetup               PASS      492.93 seconds
TestRunner_l2cap-tester       PASS      24.15 seconds
TestRunner_iso-tester         PASS      72.15 seconds
TestRunner_bnep-tester        PASS      6.16 seconds
TestRunner_mgmt-tester        FAIL      113.15 seconds
TestRunner_rfcomm-tester      PASS      9.37 seconds
TestRunner_sco-tester         PASS      14.31 seconds
TestRunner_ioctl-tester       PASS      9.98 seconds
TestRunner_mesh-tester        FAIL      12.37 seconds
TestRunner_smp-tester         PASS      8.55 seconds
TestRunner_userchan-tester    PASS      7.28 seconds
IncrementalBuild              PENDING   0.51 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 490, Passed: 484 (98.8%), Failed: 2, Not Run: 4

Failed Test Cases

Read Exp Feature - Success                           Failed       0.106 seconds
LL Privacy - Set Flags 3 (2 Devices to RL)           Failed       0.181 seconds

##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    2.775 seconds
Mesh - Send cancel - 2                               Timed out    1.997 seconds

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:

---
Regards,
Linux Bluetooth

Greg KH

maintainer

2025-10-08 04:58 UTC #11 lore raw

In reply to pip-izony

Quoted 39 lines · pip-izony

From: Seungjin Bae <[email protected]>
The bfusb_rx_complete() function parses incoming URB data in while loop. The logic does not sufficiently validate the remaining buffer size(count) accross loop iterations, which can lead to a buffer over-read.
For example, with 4-bytes remaining buffer, if the first iteration takes the hdr & 0x4000 branch, 2-bytes are consumed. On the next iteration, only 2-bytes remain, but the else branch is trying to access the third byte(buf[2]). This causes an out-of-bounds read and a potential kernel panic.
This patch fixes the vulnerability by adding checks to ensure enough data remains in the buffer before it is accessed.
Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by Seungjin Bae <[email protected]>
---
 drivers/bluetooth/bfusb.c | 4 ++++
 1 file changed, 4 insertions(+)
drivers/bluetooth/bfusb.c +4 -0
index 8df310983bf6..f17eae6dbd7d 100644
@@ -360,6 +360,10 @@ static void bfusb_rx_complete(struct urb *urb)
 			count -= 2;
 			buf   += 2;
 		} else {
+            if (count < 3) {
+                bf_dev_err(data->hdev, "block header is too short");
+                break;
+            }
 			len = (buf[2] == 0) ? 256 : buf[2];
 			count -= 3;
 			buf   += 3;
Signature · 1 line
2.43.0

This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

kernel test robot

build bot

2025-10-09 08:47 UTC #12 lore raw

In reply to pip-izony

FYI: kernel test robot notices the stable kernel rule is not satisfied.

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Rule: add the tag "Cc: [email protected]" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop

Link https://lore.kernel.org/stable/20251007232941.3742133-2-eeodqql09%40gmail.com open here

Signature · 2 lines

0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki