From: 'Simon Horman' <[email protected]> This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- idpf: fix RSS LUT memcpy size
This commit increases the memcpy size when retrieving the RSS lookup table to account for the full buffer size rather than just the number of entries. It also adjusts the required Rx buffer size check to include the structure size. Link: https://sashiko.dev/#/patchset/20260323174052.5355-1-larysa.zaremba%40intel.com?part=8 > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c > b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c > index be66f9b2e101c..0fc7c68447f83 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c > @@ -2915,8 +2915,9 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter > *adapter, > if (reply_sz < sizeof(struct virtchnl2_rss_lut)) > return -EIO; > > - lut_buf_size = le16_to_cpu(recv_rl->lut_entries) * sizeof(u32); > - if (reply_sz < lut_buf_size) > + lut_buf_size = flex_array_size(recv_rl, lut, > + le16_to_cpu(recv_rl->lut_entries)); > + if (reply_sz < lut_buf_size + sizeof(struct virtchnl2_rss_lut)) > return -EIO; Could this cause an out-of-bounds read if the message size exceeds the allocated buffer? Looking at the allocation of recv_rl earlier in this function, it has a fixed size: recv_rl = kzalloc(IDPF_CTLQ_MAX_BUF_LEN, GFP_KERNEL); If the hardware-controlled recv_rl->lut_entries yields a calculated structure size larger than IDPF_CTLQ_MAX_BUF_LEN, reply_sz may also exceed IDPF_CTLQ_MAX_BUF_LEN. While this check ensures reply_sz is large enough for lut_buf_size, does it ensure we don't read past the end of the IDPF_CTLQ_MAX_BUF_LEN allocation during the memcpy? [ ... ] > @@ -2933,7 +2934,7 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter > *adapter, > } > > do_memcpy: > - memcpy(rss_data->rss_lut, recv_rl->lut, rss_data->rss_lut_size); > + memcpy(rss_data->rss_lut, recv_rl->lut, lut_buf_size); Does this copy skip necessary byte-order conversions? The hardware response recv_rl->lut contains __le32 (little-endian) values, but the destination rss_data->rss_lut is an array of host-order u32 integers. The set path correctly applies cpu_to_le32() to elements before sending them: rl->lut[i] = rxhash_ena ? cpu_to_le32(rss_data->rss_lut[i]) : 0; On big-endian architectures, copying little-endian bytes directly with memcpy() will result in byte-swapped queue indices. Does the driver need to iterate over the entries and convert each using le32_to_cpu() instead?
