| Message ID | 20240327231826.1725488-1-andrew@daynix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/1] vhost: Added pad cleanup if vnet_hdr is not present. | expand |
On Thu, Mar 28, 2024 at 7:44 AM Andrew Melnychenko <andrew@daynix.com> wrote: > > When the Qemu launched with vhost but without tap vnet_hdr, > vhost tries to copy vnet_hdr from socket iter with size 0 > to the page that may contain some trash. > That trash can be interpreted as unpredictable values for > vnet_hdr. > That leads to dropping some packets and in some cases to > stalling vhost routine when the vhost_net tries to process > packets and fails in a loop. > > Qemu options: > -netdev tap,vhost=on,vnet_hdr=off,... > > From security point of view, wrong values on field used later > tap's tap_get_user_xdp() and will affect skb gso and options. > Later the header(and data in headroom) should not be used by the stack. > Using custom socket as a backend to vhost_net can reveal some data > in the vnet_hdr, although it would require kernel access to implement. > > The issue happens because the value of sock_len in virtqueue is 0. > That value is set at vhost_net_set_features() with > VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open() > and reset() routine. > So, currently, to trigger the issue, we need to set up qemu with > vhost=on,vnet_hdr=off, or do not configure vhost in the custom program. > > Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> It seems it has been merged by Michael. Thanks > --- > drivers/vhost/net.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index f2ed7167c848..57411ac2d08b 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -735,6 +735,9 @@ static int vhost_net_build_xdp(struct vhost_net_virtqueue *nvq, > hdr = buf; > gso = &hdr->gso; > > + if (!sock_hlen) > + memset(buf, 0, pad); > + > if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && > vhost16_to_cpu(vq, gso->csum_start) + > vhost16_to_cpu(vq, gso->csum_offset) + 2 > > -- > 2.43.0 >
Thanks, I'll look into it. On Thu, Mar 28, 2024 at 6:03 AM Jason Wang <jasowang@redhat.com> wrote: > > On Thu, Mar 28, 2024 at 7:44 AM Andrew Melnychenko <andrew@daynix.com> wrote: > > > > When the Qemu launched with vhost but without tap vnet_hdr, > > vhost tries to copy vnet_hdr from socket iter with size 0 > > to the page that may contain some trash. > > That trash can be interpreted as unpredictable values for > > vnet_hdr. > > That leads to dropping some packets and in some cases to > > stalling vhost routine when the vhost_net tries to process > > packets and fails in a loop. > > > > Qemu options: > > -netdev tap,vhost=on,vnet_hdr=off,... > > > > From security point of view, wrong values on field used later > > tap's tap_get_user_xdp() and will affect skb gso and options. > > Later the header(and data in headroom) should not be used by the stack. > > Using custom socket as a backend to vhost_net can reveal some data > > in the vnet_hdr, although it would require kernel access to implement. > > > > The issue happens because the value of sock_len in virtqueue is 0. > > That value is set at vhost_net_set_features() with > > VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open() > > and reset() routine. > > So, currently, to trigger the issue, we need to set up qemu with > > vhost=on,vnet_hdr=off, or do not configure vhost in the custom program. > > > > Signed-off-by: Andrew Melnychenko <andrew@daynix.com> > > Acked-by: Jason Wang <jasowang@redhat.com> > > It seems it has been merged by Michael. > > Thanks > > > --- > > drivers/vhost/net.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > > index f2ed7167c848..57411ac2d08b 100644 > > --- a/drivers/vhost/net.c > > +++ b/drivers/vhost/net.c > > @@ -735,6 +735,9 @@ static int vhost_net_build_xdp(struct vhost_net_virtqueue *nvq, > > hdr = buf; > > gso = &hdr->gso; > > > > + if (!sock_hlen) > > + memset(buf, 0, pad); > > + > > if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && > > vhost16_to_cpu(vq, gso->csum_start) + > > vhost16_to_cpu(vq, gso->csum_offset) + 2 > > > -- > > 2.43.0 > > >
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index f2ed7167c848..57411ac2d08b 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -735,6 +735,9 @@ static int vhost_net_build_xdp(struct vhost_net_virtqueue *nvq, hdr = buf; gso = &hdr->gso; + if (!sock_hlen) + memset(buf, 0, pad); + if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && vhost16_to_cpu(vq, gso->csum_start) + vhost16_to_cpu(vq, gso->csum_offset) + 2 >
When the Qemu launched with vhost but without tap vnet_hdr, vhost tries to copy vnet_hdr from socket iter with size 0 to the page that may contain some trash. That trash can be interpreted as unpredictable values for vnet_hdr. That leads to dropping some packets and in some cases to stalling vhost routine when the vhost_net tries to process packets and fails in a loop. Qemu options: -netdev tap,vhost=on,vnet_hdr=off,... From security point of view, wrong values on field used later tap's tap_get_user_xdp() and will affect skb gso and options. Later the header(and data in headroom) should not be used by the stack. Using custom socket as a backend to vhost_net can reveal some data in the vnet_hdr, although it would require kernel access to implement. The issue happens because the value of sock_len in virtqueue is 0. That value is set at vhost_net_set_features() with VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open() and reset() routine. So, currently, to trigger the issue, we need to set up qemu with vhost=on,vnet_hdr=off, or do not configure vhost in the custom program. Signed-off-by: Andrew Melnychenko <andrew@daynix.com> --- drivers/vhost/net.c | 3 +++ 1 file changed, 3 insertions(+)