aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFiona Ebner <f.ebner@proxmox.com>2022-08-25 11:29:10 +0200
committerJason Wang <jasowang@redhat.com>2023-02-17 13:31:33 +0800
commit099a63828130843741d317cb28e936f468b2b53b (patch)
tree0cdf73ec5c35e4f7cb687f6164c30ee97c95cafc
parent44c94cdb21cd1d1fb9aa6554585b94aa6de7ed9d (diff)
downloadqemu-099a63828130843741d317cb28e936f468b2b53b.zip
qemu-099a63828130843741d317cb28e936f468b2b53b.tar.gz
qemu-099a63828130843741d317cb28e936f468b2b53b.tar.bz2
hw/net/vmxnet3: allow VMXNET3_MAX_MTU itself as a value
Currently, VMXNET3_MAX_MTU itself (being 9000) is not considered a valid value for the MTU, but a guest running ESXi 7.0 might try to set it and fail the assert [0]. In the Linux kernel, dev->max_mtu itself is a valid value for the MTU and for the vmxnet3 driver it's 9000, so a guest running Linux will also fail the assert when trying to set an MTU of 9000. VMXNET3_MAX_MTU and s->mtu don't seem to be used in relation to buffer allocations/accesses, so allowing the upper limit itself as a value should be fine. [0]: https://forum.proxmox.com/threads/114011/ Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate (CVE-2021-20203)") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
-rw-r--r--hw/net/vmxnet3.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index d2ab527..56559cd 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -1441,7 +1441,7 @@ static void vmxnet3_activate_device(VMXNET3State *s)
vmxnet3_setup_rx_filtering(s);
/* Cache fields from shared memory */
s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu);
- assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU);
+ assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu <= VMXNET3_MAX_MTU);
VMW_CFPRN("MTU is %u", s->mtu);
s->max_rx_frags =