From: Bui Quang Minh minhquangbui99@gmail.com Sent: 27 October 2025 08:19 PM
On 10/25/25 14:11, Parav Pandit wrote:
From: Bui Quang Minh minhquangbui99@gmail.com 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?