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;
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;
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
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>
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Paul Menzel -
pip-izony