RE: [PATCH net v5] virtio-net: fix received length check in big packets

[Parav Pandit]

> From: Bui Quang Minh <minhquangbui99@xxxxxxxxx>
> Sent: 27 October 2025 08:19 PM
> 
> On 10/25/25 14:11, Parav Pandit wrote:
> >> From: Bui Quang Minh <minhquangbui99@xxxxxxxxx>
> >> Sent: 24 October 2025 08:37 PM
> >>
> >> Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length
> >> for big packets"), when guest gso is off, the allocated size for big
> >> packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on
> >> negotiated MTU. The number of allocated frags for big packets is
> >> stored in vi-
> >>> big_packets_num_skbfrags.
> >> Because the host announced buffer length can be malicious (e.g. the
> >> host vhost_net driver's get_rx_bufs is modified to announce incorrect
> >> length), we need a check in virtio_net receive path. Currently, the
> >> check is not adapted to the new change which can lead to NULL page
> >> pointer dereference in the below while loop when receiving length that is
> larger than the allocated one.
> >>
> > This looks wrong.
> > A device DMAed N bytes, and it reports N + M bytes in the completion?
> > Such devices should be fixed.
> >
> > If driver allocated X bytes, and device copied X + Y bytes on receive packet, it
> will crash the driver host anyway.
> >
> > The fixes tag in this patch is incorrect because this is not a driver bug.
> > It is just adding resiliency in driver for broken device. So driver cannot have
> fixes tag here.
> 
> Yes, I agree that the check is a protection against broken device.
> 
> The check is already there before this commit, but it is not correct since the
> changes in commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length
> for big packets"). So this patch fixes the check corresponding to the new
> change. I think this is a valid use of Fixes tag.

I am missing something.
If you don’t have the broken device, what part if wrong in the patch which needs fixes tag?