Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate
(CVE-2021-20203)")
Signed-off-by: Fiona Ebner <f.eb...@proxmox.com>
---
I'm not familiar with this code, so really I'm asking: is the change
justified?
I tested the change and it seems to work, but I only have some rough
rationale for it, which is also why there's no commit message yet.
In the Linux kernel's net/core/dev.c, in dev_validate_mtu(), the upper
limit itself is a valid value:
if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
NL_SET_ERR_MSG(extack, "mtu greater than device maximum");
return -EINVAL;
}
and AFAICT in the case of the vmxnet3 driver, max_mtu is set to
VMXNET3_MAX_MTU (as defined in the kernel, which is 9000, same as in
QEMU).
Reported by one of our users running into the failing assert():
https://forum.proxmox.com/threads/114011/#post-492916
hw/net/vmxnet3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 0b7acf7f89..a2037583bf 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 =
--
2.30.2
