[PATCH] Bluetooth: btintel_pcie: validate RX packet length against buffer size

[PATCH] Bluetooth: btintel_pcie: validate RX packet length against buffer size

[moonafterrain]

btintel_pcie_submit_rx_work() reads packet_len from an rfh_hdr in
DMA-coherent memory and uses it as the length for skb_put_data() without
upper bound validation. Since packet_len is a 16-bit field (0-65535) but
each RX DMA buffer is only BTINTEL_PCIE_BUFFER_SIZE (4096) bytes, a
malicious or malfunctioning firmware could set a large packet_len,
causing an out-of-bounds read beyond the buffer into adjacent kernel
heap memory.

Add a check that packet_len does not exceed the available payload space
alongside the existing zero-length check.

Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/bluetooth/btintel_pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
index 37b744e35bc4..9dd02e8af2a0 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -1360,7 +1360,8 @@ static int btintel_pcie_submit_rx_work(struct btintel_pcie_data *data, u8 status
 	rfh_hdr = buf;
 
 	len = rfh_hdr->packet_len;
-	if (len <= 0) {
+	if (len <= 0 ||
+	    len > BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr)) {
 		ret = -EINVAL;
 		goto resubmit;
 	}

---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260317-fixes-2efba1c4768b

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

Re: [PATCH] Bluetooth: btintel_pcie: validate RX packet length against buffer size

[Paul Menzel]

Dear Junrui,


Thank you for your patch. It be great if you configured your name in the 
author line – currently it only contains the address:

     From: moonafterrain@outlook.com

No idea, why b4 is not doing it.

Am 17.03.26 um 07:04 schrieb moonafterrain@outlook.com:
> btintel_pcie_submit_rx_work() reads packet_len from an rfh_hdr in
> DMA-coherent memory and uses it as the length for skb_put_data() without
> upper bound validation. Since packet_len is a 16-bit field (0-65535) but
> each RX DMA buffer is only BTINTEL_PCIE_BUFFER_SIZE (4096) bytes, a
> malicious or malfunctioning firmware could set a large packet_len,
> causing an out-of-bounds read beyond the buffer into adjacent kernel
> heap memory.
> 
> Add a check that packet_len does not exceed the available payload space
> alongside the existing zero-length check.

Do you have a reproducer or test case for this issue?

> Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
>   drivers/bluetooth/btintel_pcie.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
> index 37b744e35bc4..9dd02e8af2a0 100644
> --- a/drivers/bluetooth/btintel_pcie.c
> +++ b/drivers/bluetooth/btintel_pcie.c
> @@ -1360,7 +1360,8 @@ static int btintel_pcie_submit_rx_work(struct btintel_pcie_data *data, u8 status
>   	rfh_hdr = buf;
>   
>   	len = rfh_hdr->packet_len;
> -	if (len <= 0) {
> +	if (len <= 0 ||
> +	    len > BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr)) {
>   		ret = -EINVAL;

As this seems a broken or malicious firmware, no idea, if it’d make 
sense to log it.

>   		goto resubmit;
>   	}

The diff looks good:

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

Re: [PATCH] Bluetooth: btintel_pcie: validate RX packet length against buffer size

[Junrui Luo]

Hi Paul, 


Thanks for the review.

On Wed, Mar 18, 2026 at 10:12:35AM +0100, Paul Menzel wrote:
> Thank you for your patch. It be great if you configured your name in the
> author line – currently it only contains the address:
> 
>     From: moonafterrain@outlook.com
> 
> No idea, why b4 is not doing it.

Sorry about that. I will fix in v2.

> Do you have a reproducer or test case for this issue?

This was found through static analysis. It can be triggered
theoretically by a malicious or broken device.

> As this seems a broken or malicious firmware, no idea, if it’d make sense to
> log it.

Would it make sense to add a bt_dev_warn() to log the invalid
packet_len? If so, I will include it in v2.

Thanks,
Junrui Luo