On 30/06/2025 20:28, Alex Williamson wrote:
On Sun, 29 Jun 2025 09:58:43 +0000
Artem Sadovnikov <a.sadovnikov@xxxxxxxxx> wrote:
MLX cap pg_track_log_max_msg_size consists of 5 bits, value of which is
used as power of 2 for max_msg_size. This can lead to multiplication
overflow between max_msg_size (u32) and integer constant, and afterwards
incorrect value is being written to rq_size.
Fix this issue by extending max_msg_size up to u64 so multiplication will
be extended to u64.
Personally I'd go with changing the multiplier to 4ULL rather than
changing the storage size here, but let's wait for Yishai and Jason.
Thanks,
Alex
Yes, let's go with Alex's suggestion.
max_msg_size based on the CAP, can't be larger than u32.
Yishai
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Artem Sadovnikov <a.sadovnikov@xxxxxxxxx>
---
drivers/vfio/pci/mlx5/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/mlx5/cmd.c b/drivers/vfio/pci/mlx5/cmd.c
index 5b919a0b2524..0bdaf1d23a78 100644
--- a/drivers/vfio/pci/mlx5/cmd.c
+++ b/drivers/vfio/pci/mlx5/cmd.c
@@ -1503,7 +1503,7 @@ int mlx5vf_start_page_tracker(struct vfio_device *vdev,
struct mlx5_vhca_qp *fw_qp;
struct mlx5_core_dev *mdev;
u32 log_max_msg_size;
- u32 max_msg_size;
+ u64 max_msg_size;
u64 rq_size = SZ_2M;
u32 max_recv_wr;
int err;
