On Wed, Jul 08, 2026 at 04:22:42PM +0100, [email protected] wrote: > From: Enrico Zanda <[email protected]> > > When vhost owns the virtio-net header, i.e. when > VHOST_NET_F_VIRTIO_NET_HDR is negotiated, sock_hlen is 0, > meaning that no header will be forwarded to the TAP device. > > In the current vhost_net_build_xdp() implementation, > when sock_hlen == 0, the gso pointer can point at the start of the > Ethernet frame instead of a virtio-net header. > This results in a wrong interpretation of the destination MAC address > bytes as struct virtio_net_hdr fields. > > This can, for some MAC addresses, trigger -EINVAL and return early > before the TX descriptor is completed, which can stall vhost-net TX. > > Before 97b2409f28e0, the gso pointer was set to the zeroed padding area, > using it as a synthetic virtio-net header. Restore that behavior. > > Fixes: 97b2409f28e0 ("vhost-net: reduce one userspace copy when building XDP > buff") > Signed-off-by: Enrico Zanda <[email protected]>
The fix looks good: Acked-by: Michael S. Tsirkin <[email protected]> Sashiko thinks there's something something security here, but I think it is misguided. It's just guest hurting itself. driver breaks the device it gets to keep both pieces. > --- > drivers/vhost/net.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 77b59f49bddb..3e72b9c6af0c 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -731,10 +731,12 @@ static int vhost_net_build_xdp(struct > vhost_net_virtqueue *nvq, > goto err; > } > > - gso = buf + pad - sock_hlen; > - > - if (!sock_hlen) > + if (!sock_hlen) { > memset(buf, 0, pad); > + gso = buf; > + } else { > + gso = buf + pad - sock_hlen; > + } > > if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && > vhost16_to_cpu(vq, gso->csum_start) + > -- > 2.43.0
