linux-kernel - Re: [PATCH] vdpa/mlx5: fix param validation in mlx5_vdpa_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210210100821.aaye2cgmrpwhhzgn@steredhat>
Date:   Wed, 10 Feb 2021 11:08:21 +0100
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        virtualization@...ts.linux-foundation.org,
        Parav Pandit <parav@...dia.com>, Eli Cohen <elic@...dia.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: fix param validation in mlx5_vdpa_get_config()

On Tue, Feb 09, 2021 at 04:31:23AM -0500, Michael S. Tsirkin wrote:
>On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
>>
>> On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
>> > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>> > > It's legal to have 'offset + len' equal to
>> > > sizeof(struct virtio_net_config), since 'ndev->config' is a
>> > > 'struct virtio_net_config', so we can safely copy its content under
>> > > this condition.
>> > >
>> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
>> > > Cc: stable@...r.kernel.org
>> > > Signed-off-by: Stefano Garzarella <sgarzare@...hat.com>
>> > > ---
>> > >   drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>> > >   1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > index dc88559a8d49..10e9b09932eb 100644
>> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
>> > >   	struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>> > >   	struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>> > > -	if (offset + len < sizeof(struct virtio_net_config))
>> > > +	if (offset + len <= sizeof(struct virtio_net_config))
>> > >   		memcpy(buf, (u8 *)&ndev->config + offset, len);
>> > >   }
>> > Actually first I am not sure we need these checks at all.
>> > vhost_vdpa_config_validate already validates the values, right?
>>
>>
>> I think they're working at different levels. There's no guarantee that
>> vhost-vdpa is the driver for this vdpa device.
>
>In fact, get_config returns void, so userspace can easily get
>trash if it passes incorrect parameters by mistake, there is
>no way for userspace to find out whether that is the case :(
>
>Any objections to returning the # of bytes copied, or -1
>on error?

Make sense for me, but are we sure we don't break userspace if we return 
the number of bytes instead of 0 on success?

I had a quick look at QEMU and it looks like we consider success if the 
return value is >= 0, but I need to check further.

>
>>
>> >
>> > Second, what will happen when we extend the struct and then
>> > run new userspace on an old kernel? Looks like it will just
>> > fail right? So what is the plan?
>>
>>
>> In this case, get_config() should match the spec behaviour. That is to say
>> the size of config space depends on the feature negotiated.
>>
>> Thanks
>
>Yes but spec says config space can be bigger than specified by features:
>
>	Drivers MUST NOT limit structure size and device configuration space size. Instead, drivers SHOULD only
>	check that device configuration space is large enough to contain the fields necessary for device operation.
>

So IIUC in the driver we should copy as much as we can.

If you agree, I can send an RFC series and we can continue the 
discussion on it, but I think we should queue this patch for stable 
branches.

Thanks,
Stefano