On 7/8/26 6:50 PM, Michael S. Tsirkin wrote: > 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. Out of sheer curiosity: which sashiko instance? AFAICS both gemini and nipa are clean:
https://sashiko.dev/#/patchset/20260708152242.2268848-1-enrico.zanda%40arm.com https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260708152242.2268848-1-enrico.zanda%40arm.com /P
