| Message ID | 20240924-rss-v4-4-84e932ec0e6c@daynix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | tun: Introduce virtio-net hashing feature | expand |
diff --git a/drivers/net/tap.c b/drivers/net/tap.c index 77574f7a3bd4..ba044302ccc6 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -813,7 +813,7 @@ static ssize_t tap_put_user(struct tap_queue *q, sizeof(vnet_hdr)) return -EFAULT; - iov_iter_advance(iter, vnet_hdr_len - sizeof(vnet_hdr)); + iov_iter_zero(vnet_hdr_len - sizeof(vnet_hdr), iter); } total = vnet_hdr_len; total += skb->len;
tap used to simply advance iov_iter when it needs to pad virtio header, which leaves the garbage in the buffer as is. This is especially problematic when tap starts to allow enabling the hash reporting feature; even if the feature is enabled, the packet may lack a hash value and may contain a hole in the virtio header because the packet arrived before the feature gets enabled or does not contain the header fields to be hashed. If the hole is not filled with zero, it is impossible to tell if the packet lacks a hash value. In theory, a user of tap can fill the buffer with zero before calling read() to avoid such a problem, but leaving the garbage in the buffer is awkward anyway so fill the buffer in tap. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> --- drivers/net/tap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)