> From: Bui Quang Minh <[email protected]> > Sent: 27 October 2025 08:19 PM > > On 10/25/25 14:11, Parav Pandit wrote: > >> From: Bui Quang Minh <[email protected]> > >> 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?
