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 <[email protected]> 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/[email protected]?part=8
