Re: [PATCH net-next v2 08/14] iavf: temporary rename of IAVF_MAX_REQ_QUEUES to IAVF_MAX_REQ_QUEUES_VCV1

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: iavf: missing bounds check on num_vsis causes out-of-bounds write
--

commit 96fe4c02ff0c0cd29e48e38845a6fbbedd204284
Author: Przemek Kitszel <przemyslaw.kitszel@intel.com>

iavf: temporary rename of IAVF_MAX_REQ_QUEUES to IAVF_MAX_REQ_QUEUES_VCV1

Rename IAVF_MAX_REQ_QUEUES to IAVF_MAX_REQ_QUEUES_VCV1, in preparation for
the next patch that will extend the max to 256, using old value of 16 for
the "v1" variant of virtchnl opcodes.

> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -268,19 +268,19 @@ int iavf_send_vf_ptp_caps_msg(struct iavf_adapter *adapter)
>   **/
>  static void iavf_validate_num_queues(struct iavf_adapter *adapter)
>  {
> -	if (adapter->vf_res->num_queue_pairs > IAVF_MAX_REQ_QUEUES) {
> +	if (adapter->vf_res->num_queue_pairs > IAVF_MAX_REQ_QUEUES_VCV1) {
>  		struct virtchnl_vsi_resource *vsi_res;
>  		int i;
>  
>  		dev_info(&adapter->pdev->dev, "Received %d queues, but can only have a max of %d\n",
>  			 adapter->vf_res->num_queue_pairs,
> -			 IAVF_MAX_REQ_QUEUES);
> +			 IAVF_MAX_REQ_QUEUES_VCV1);
>  		dev_info(&adapter->pdev->dev, "Fixing by reducing queues to %d\n",
> -			 IAVF_MAX_REQ_QUEUES);
> -		adapter->vf_res->num_queue_pairs = IAVF_MAX_REQ_QUEUES;
> +			 IAVF_MAX_REQ_QUEUES_VCV1);
> +		adapter->vf_res->num_queue_pairs = IAVF_MAX_REQ_QUEUES_VCV1;
>  		for (i = 0; i < adapter->vf_res->num_vsis; i++) {
>  			vsi_res = &adapter->vf_res->vsi_res[i];
> -			vsi_res->num_queue_pairs = IAVF_MAX_REQ_QUEUES;
> +			vsi_res->num_queue_pairs = IAVF_MAX_REQ_QUEUES_VCV1;

[Severity: High]
Can a maliciously large num_vsis value from the PF cause an out-of-bounds
write here?

In iavf_get_vf_config(), the message from the PF is copied into
adapter->vf_res without validating num_vsis against the allocation
size:

	memcpy(adapter->vf_res, event.msg_buf, min(event.msg_len, len));

	/* some PFs send more queues than we should have so validate that
	 * we aren't getting too many queues
	 */
	if (!err)
		iavf_validate_num_queues(adapter);

When iavf_validate_num_queues() runs, if the PF sent a num_queue_pairs
value greater than 16, this loop will iterate from 0 up to the unvalidated
adapter->vf_res->num_vsis.

If num_vsis exceeds the allocated size, this assignment writes the value 16
repeatedly into adjacent out-of-bounds heap memory. In confidential computing
environments, could a malicious PF use this to corrupt the VF kernel memory?

It does not appear that a bounds check is added in subsequent patches in
this series.

>  		}
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009121433.30347-1-przemyslaw.kitszel@intel.com?part=8