| commit | 099a63828130843741d317cb28e936f468b2b53b | |
| author | Fiona Ebner <f.ebner@proxmox.com> | |
| Thu, 25 Aug 2022 09:29:10 +0000 (25 11:29 +0200) | ||
| committer | Jason Wang <jasowang@redhat.com> | |
| Fri, 17 Feb 2023 05:31:33 +0000 (17 13:31 +0800) | ||
| tree | 0cdf73ec5c35e4f7cb687f6164c30ee97c95cafc | treesnapshot (tar.gz zip) |
| parent | 44c94cdb21cd1d1fb9aa6554585b94aa6de7ed9d | commitdiff |
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>
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>
| hw/net/vmxnet3.c | diffblobblamehistory |