Re: [PATCH 3/6] Bluetooth: btqca: Add IPQ5018 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Out-of-bounds read of tag_id and tag_len via integer underflow in qca_tlv_check_data.
--

commit 513dbc31af180171927da878907af8ede1372fc7
Author: George Moussalem <george.moussalem@outlook.com>

Bluetooth: btqca: Add IPQ5018 support

Add the IPQ5018 SoC type and support for loading its firmware.

> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -378,6 +378,9 @@ static int qca_tlv_check_data(struct hci_dev *hdev,
>  		break;
>  
>  	case TLV_TYPE_NVM:
> +		if (soc_type == QCA_IPQ5018)
> +			break;
> +
>  		if (fw_size < sizeof(struct tlv_type_hdr))
>  			return -EINVAL;

[ ... ]

>  		idx = 0;
>  		data = tlv->data;
>  		while (idx < length - sizeof(struct tlv_type_nvm)) {
>  			tlv_nvm = (struct tlv_type_nvm *)(data + idx);
> 
>  			tag_id = le16_to_cpu(tlv_nvm->tag_id);
>  			tag_len = le16_to_cpu(tlv_nvm->tag_len);

[Severity: High]
This is a pre-existing issue, but does this loop risk an out-of-bounds read
if length is less than the size of struct tlv_type_nvm?

Since sizeof(struct tlv_type_nvm) evaluates to an unsigned size_t, a small
length (like 0 or 1) will cause the subtraction to underflow and wrap around
to a very large positive value.

This would cause the while loop condition in qca_tlv_check_data() to
incorrectly evaluate to true. The assignments to tag_id and tag_len would
then read 4 bytes of memory, which could be out of bounds of the allocated
firmware buffer if a malformed or truncated TLV_TYPE_NVM file is processed.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-ipq5018-bluetooth-v1-0-d999be0e04f7@outlook.com?part=3