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.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Artem Sadovnikov <a.sadovnikov@ispras.ru>
---
 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;
-- 
2.43.0

On Sun, 29 Jun 2025 09:58:43 +0000
Artem Sadovnikov <a.sadovnikov@ispras.ru> 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

> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Signed-off-by: Artem Sadovnikov <a.sadovnikov@ispras.ru>
> ---
>  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;

On 30/06/2025 20:28, Alex Williamson wrote:
> On Sun, 29 Jun 2025 09:58:43 +0000
> Artem Sadovnikov <a.sadovnikov@ispras.ru> 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@ispras.ru>
>> ---
>>   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;
>