* [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
@ 2025-10-07 23:29 pip-izony
2025-10-08 1:17 ` bluez.test.bot
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: pip-izony @ 2025-10-07 23:29 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Seungjin Bae, Kyungtae Kim, Luiz Augusto von Dentz, linux-kernel,
linux-bluetooth, stable
From: Seungjin Bae <eeodqql09@gmail.com>
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 <eeodqql09@gmail.com>
---
drivers/bluetooth/bfusb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
index 8df310983bf6..f17eae6dbd7d 100644
--- a/drivers/bluetooth/bfusb.c
+++ b/drivers/bluetooth/bfusb.c
@@ -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;
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* RE: Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-07 23:29 [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop pip-izony
@ 2025-10-08 1:17 ` bluez.test.bot
2025-10-08 1:56 ` [PATCH v2] " pip-izony
2025-10-08 4:58 ` [PATCH] " Greg KH
2 siblings, 0 replies; 12+ messages in thread
From: bluez.test.bot @ 2025-10-08 1:17 UTC (permalink / raw)
To: linux-bluetooth, eeodqql09
[-- Attachment #1: Type: text/plain, Size: 11705 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/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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-07 23:29 [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop pip-izony
2025-10-08 1:17 ` bluez.test.bot
@ 2025-10-08 1:56 ` pip-izony
2025-10-08 3:01 ` [v2] " bluez.test.bot
2025-10-08 3:51 ` [PATCH v2] " Paul Menzel
2025-10-08 4:58 ` [PATCH] " Greg KH
2 siblings, 2 replies; 12+ messages in thread
From: pip-izony @ 2025-10-08 1:56 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Seungjin Bae, Kyungtae Kim, Luiz Augusto von Dentz, linux-kernel,
linux-bluetooth, stable
From: Seungjin Bae <eeodqql09@gmail.com>
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 <eeodqql09@gmail.com>
---
v1 -> v2: Fixing the error function name
drivers/bluetooth/bfusb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
index 8df310983bf6..45f4ec5b6860 100644
--- a/drivers/bluetooth/bfusb.c
+++ b/drivers/bluetooth/bfusb.c
@@ -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;
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* RE: [v2] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-08 1:56 ` [PATCH v2] " pip-izony
@ 2025-10-08 3:01 ` bluez.test.bot
2025-10-08 3:51 ` [PATCH v2] " Paul Menzel
1 sibling, 0 replies; 12+ messages in thread
From: bluez.test.bot @ 2025-10-08 3:01 UTC (permalink / raw)
To: linux-bluetooth, eeodqql09
[-- Attachment #1: Type: text/plain, Size: 2297 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/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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-08 1:56 ` [PATCH v2] " pip-izony
2025-10-08 3:01 ` [v2] " bluez.test.bot
@ 2025-10-08 3:51 ` Paul Menzel
2025-10-09 2:57 ` [PATCH v3] " pip-izony
1 sibling, 1 reply; 12+ messages in thread
From: Paul Menzel @ 2025-10-08 3:51 UTC (permalink / raw)
To: Seungjin Bae
Cc: Marcel Holtmann, Kyungtae Kim, Luiz Augusto von Dentz,
linux-kernel, linux-bluetooth, stable
Dear Seungjin,
Thank you for the patch.
Am 08.10.25 um 03:56 schrieb pip-izony:
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> The bfusb_rx_complete() function parses incoming URB data in while loop.
… in *a* while loop.
> The logic does not sufficiently validate the remaining buffer size(count)
> accross loop iterations, which can lead to a buffer over-read.
across
> 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.
> 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 <eeodqql09@gmail.com>
> ---
> v1 -> v2: Fixing the error function name
>
> drivers/bluetooth/bfusb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index 8df310983bf6..45f4ec5b6860 100644
> --- a/drivers/bluetooth/bfusb.c
> +++ b/drivers/bluetooth/bfusb.c
> @@ -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.
> + break;
> + }
Please use tabs for alignment. `scripts/checkpatch.pl` should have
warned about this.
> len = (buf[2] == 0) ? 256 : buf[2];
> count -= 3;
> buf += 3;
Kind regards,
Paul
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-07 23:29 [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop pip-izony
2025-10-08 1:17 ` bluez.test.bot
2025-10-08 1:56 ` [PATCH v2] " pip-izony
@ 2025-10-08 4:58 ` Greg KH
2 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2025-10-08 4:58 UTC (permalink / raw)
To: pip-izony
Cc: Marcel Holtmann, Kyungtae Kim, Luiz Augusto von Dentz,
linux-kernel, linux-bluetooth, stable
On Tue, Oct 07, 2025 at 07:29:42PM -0400, pip-izony wrote:
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> 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 <eeodqql09@gmail.com>
> ---
> drivers/bluetooth/bfusb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index 8df310983bf6..f17eae6dbd7d 100644
> --- a/drivers/bluetooth/bfusb.c
> +++ b/drivers/bluetooth/bfusb.c
> @@ -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;
> --
> 2.43.0
>
>
<formletter>
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-08 3:51 ` [PATCH v2] " Paul Menzel
@ 2025-10-09 2:57 ` pip-izony
2025-10-09 3:50 ` [v3] " bluez.test.bot
2025-10-09 7:01 ` [PATCH v3] " Paul Menzel
0 siblings, 2 replies; 12+ messages in thread
From: pip-izony @ 2025-10-09 2:57 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Seungjin Bae, Kyungtae Kim, Luiz Augusto von Dentz, linux-kernel,
linux-bluetooth
From: Seungjin Bae <eeodqql09@gmail.com>
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 <eeodqql09@gmail.com>
---
v1 -> v2: Fixing the error function name
v2 -> v3: Addressing feedback from Paul Menzel
drivers/bluetooth/bfusb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
index 8df310983bf6..90ca5ab2acc3 100644
--- a/drivers/bluetooth/bfusb.c
+++ b/drivers/bluetooth/bfusb.c
@@ -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;
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* RE: [v3] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-09 2:57 ` [PATCH v3] " pip-izony
@ 2025-10-09 3:50 ` bluez.test.bot
2025-10-09 7:01 ` [PATCH v3] " Paul Menzel
1 sibling, 0 replies; 12+ messages in thread
From: bluez.test.bot @ 2025-10-09 3:50 UTC (permalink / raw)
To: linux-bluetooth, eeodqql09
[-- Attachment #1: Type: text/plain, Size: 2296 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/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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-09 2:57 ` [PATCH v3] " pip-izony
2025-10-09 3:50 ` [v3] " bluez.test.bot
@ 2025-10-09 7:01 ` Paul Menzel
2025-10-09 16:48 ` [PATCH v4] " pip-izony
1 sibling, 1 reply; 12+ messages in thread
From: Paul Menzel @ 2025-10-09 7:01 UTC (permalink / raw)
To: Seungjin Bae
Cc: Marcel Holtmann, Kyungtae Kim, Luiz Augusto von Dentz,
linux-kernel, linux-bluetooth
Dear Seungjin,
Thank you for the patch.
Am 09.10.25 um 04:57 schrieb pip-izony:
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> 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 <eeodqql09@gmail.com>
> ---
> v1 -> v2: Fixing the error function name
> v2 -> v3: Addressing feedback from Paul Menzel
>
> drivers/bluetooth/bfusb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index 8df310983bf6..90ca5ab2acc3 100644
> --- a/drivers/bluetooth/bfusb.c
> +++ b/drivers/bluetooth/bfusb.c
> @@ -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)
> + count);
> + break;
> + }
> len = (buf[2] == 0) ? 256 : buf[2];
> count -= 3;
> buf += 3;
Either way:
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v4] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-09 7:01 ` [PATCH v3] " Paul Menzel
@ 2025-10-09 16:48 ` pip-izony
2025-10-09 17:14 ` Luiz Augusto von Dentz
2025-10-09 17:34 ` [v4] " bluez.test.bot
0 siblings, 2 replies; 12+ messages in thread
From: pip-izony @ 2025-10-09 16:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Seungjin Bae, Kyungtae Kim, Luiz Augusto von Dentz, linux-kernel,
linux-bluetooth
From: Seungjin Bae <eeodqql09@gmail.com>
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 <eeodqql09@gmail.com>
---
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(+)
diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
index 8df310983bf6..02ba16775004 100644
--- a/drivers/bluetooth/bfusb.c
+++ b/drivers/bluetooth/bfusb.c
@@ -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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v4] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-09 16:48 ` [PATCH v4] " pip-izony
@ 2025-10-09 17:14 ` Luiz Augusto von Dentz
2025-10-09 17:34 ` [v4] " bluez.test.bot
1 sibling, 0 replies; 12+ messages in thread
From: Luiz Augusto von Dentz @ 2025-10-09 17:14 UTC (permalink / raw)
To: pip-izony; +Cc: Marcel Holtmann, Kyungtae Kim, linux-kernel, linux-bluetooth
Hi Pip-Izony,
On Thu, Oct 9, 2025 at 12:51 PM pip-izony <eeodqql09@gmail.com> wrote:
>
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> 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 <eeodqql09@gmail.com>
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.
> ---
> 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(+)
>
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index 8df310983bf6..02ba16775004 100644
> --- a/drivers/bluetooth/bfusb.c
> +++ b/drivers/bluetooth/bfusb.c
> @@ -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
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [v4] Bluetooth: bfusb: Fix buffer over-read in rx processing loop
2025-10-09 16:48 ` [PATCH v4] " pip-izony
2025-10-09 17:14 ` Luiz Augusto von Dentz
@ 2025-10-09 17:34 ` bluez.test.bot
1 sibling, 0 replies; 12+ messages in thread
From: bluez.test.bot @ 2025-10-09 17:34 UTC (permalink / raw)
To: linux-bluetooth, eeodqql09
[-- Attachment #1: Type: text/plain, Size: 2376 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/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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-10-09 17:34 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-07 23:29 [PATCH] Bluetooth: bfusb: Fix buffer over-read in rx processing loop pip-izony
2025-10-08 1:17 ` bluez.test.bot
2025-10-08 1:56 ` [PATCH v2] " pip-izony
2025-10-08 3:01 ` [v2] " bluez.test.bot
2025-10-08 3:51 ` [PATCH v2] " Paul Menzel
2025-10-09 2:57 ` [PATCH v3] " pip-izony
2025-10-09 3:50 ` [v3] " bluez.test.bot
2025-10-09 7:01 ` [PATCH v3] " Paul Menzel
2025-10-09 16:48 ` [PATCH v4] " pip-izony
2025-10-09 17:14 ` Luiz Augusto von Dentz
2025-10-09 17:34 ` [v4] " bluez.test.bot
2025-10-08 4:58 ` [PATCH] " Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox